Cherry pick 907a367b5035ab120095c325b48fdf90b04a5081 : Remove explicit width suffixes from Arm bignum assembly #399
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 Mbed-TLS#6089. Signed-off-by: Hanno Becker <hanno.becker@arm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
systems, on which the .n/.w distinction is not meaningful
(all instructions are 32-bit).
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 Mbed-TLS#6089.
Signed-off-by: Hanno Becker hanno.becker@arm.com
Notes:
Signed-off-by:line from the committer to certify that the contribution is made under the terms of the Developer Certificate of Origin.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:
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
Steps to test or reproduce
Outline the steps to test or reproduce the PR here.