GCC 10: Add driver options -mbranches-within-32B-boundaries and -malign-branch* for x86

Fāng-ruì Sòng via gcc gcc@gcc.gnu.org
Thu Jan 16 10:05:00 GMT 2020

H.J. Lu's https://sourceware.org/ml/binutils/2019-11/msg00174.html
assembler patch series added -mbranches-within-32B-boundaries and some
fine-grained tuning options to GNU as, which are considered a pretty
important performance mitigation of a serious CPU bug
and see the news around this).

It seems that there is still no GCC driver option yet. Currently users
are expected to use:

-Xassembler -mbranches-within-32B-boundaries

I think a compiler driver option will be very important, and users
should use gcc/g++/gfortran/gdc -mbranches-within-32B-boundaries
directly, instead of -Wa,/-Xassembler.

* The compiler may selectively disable some code structs from being
segment override prefixed/NOP padded. Such code may be sensitive to
the exact code sequence. This can be implemented as some assembly
directives (not yet decided). We need a mechanism to communicate this
fact to the compiler. -Wa, is too late.
* The compiler may add assembly directives only in hot code guided by
profile [3]. The code size increase[1] 1%~5% is unacceptable in many
scenarios. Avoiding annotating cold code can mitigate many code
size/memory usage increase problems.

For at least the two reasons, a compiler driver option for the
prominent user-facing option (-mbranches-within-32B-boundaries) will
be useful. An assembler option is too late to make the decisions.
Clang 10 will have a driver option -mbranches-within-32B-boundaries
(along with -malign-branch=, -malign-branch-boundary=, and

I am not clear about GCC 10 release schedule, but it seems GCC 10 is
at a fairly late stage
(https://gcc.gnu.org/ml/gcc/2020-01/msg00199.html). I send this email
in the hope that GCC 10 can have a driver option
-mbranches-within-32B-boundaries (and probably the 3 -malign-branch*),
so that users will not use -mbranches-within-32B-boundaries with one
compiler (Clang) while -Wa,-mbranches-within-32B-boundaries with
another (GCC).

[1]: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137610.html
[2]: https://reviews.llvm.org/D72721
[3]: https://reviews.llvm.org/rG5ca24d09aefaedf8e4148c7fce4b4ab0c4ecc72a


More information about the Gcc mailing list