mbedtls icon indicating copy to clipboard operation
mbedtls copied to clipboard

Cherry pick 907a367b5035ab120095c325b48fdf90b04a5081 : Remove explicit width suffixes from Arm bignum assembly

Open lhuang04 opened this issue 2 years ago • 0 comments

Within the M-profile of the Arm architecture, some instructions admit both a 16-bit and a 32-bit encoding. For those instructions, some assemblers support the use of the .n (narrow) and .w (wide) suffixes to force a choice of instruction encoding width. Forcing the size of encodings may be useful to ensure alignment of code, which can have a significant performance impact on some microarchitectures.

It is for this reason that a previous commit introduced explicit .w suffixes into what was believed to be M-profile only assembly in library/bn_mul.h.

This change, however, introduced two issues:

  • First, the assembly block in question is used also for Armv7-A systems, on which the .n/.w distinction is not meaningful (all instructions are 32-bit).
  • Second, compiler support for .n/.w suffixes appears patchy, leading to compilation failures even when building for M-profile targets.

This commit removes the .w annotations in order to restore working code, deferring controlled re-introduction for the sake of performance.

Fixes #6089.

Signed-off-by: Hanno Becker [email protected]

Notes:

  • Pull requests cannot be accepted until the PR follows the contributing guidelines. In particular, each commit must have at least one Signed-off-by: line from the committer to certify that the contribution is made under the terms of the Developer Certificate of Origin.
  • This is just a template, so feel free to use/remove the unnecessary things

Description

A few sentences describing the overall goals of the pull request's commits.

Status

READY/IN DEVELOPMENT/HOLD

Requires Backporting

When there is a bug fix, it should be backported to all maintained and supported branches. Changes do not have to be backported if:

  • This PR is a new feature\enhancement
  • This PR contains changes in the API. If this is true, and there is a need for the fix to be backported, the fix should be handled differently in the legacy branch

Yes | NO
Which branch?

Migrations

If there is any API change, what's the incentive and logic for it.

YES | NO

Additional comments

Any additional information that could be of interest

Todos

  • [ ] Tests
  • [ ] Documentation
  • [ ] Changelog updated
  • [ ] Backported

Steps to test or reproduce

Outline the steps to test or reproduce the PR here.

lhuang04 avatar Aug 22 '22 14:08 lhuang04