This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
GCC 10: Add driver options -mbranches-within-32B-boundaries and -malign-branch* for x86
- From: "Fāng-ruì Sòng via gcc" <gcc at gcc dot gnu dot org>
- To: gcc at gcc dot gnu dot org
- Cc: Philip Reames <listmail at philipreames dot com>, Fangrui Song <maskray at google dot com>, "Luo, Yuanke" <yuanke dot luo at intel dot com>, "Kan, Shengchen" <shengchen dot kan at intel dot com>, "Zhang, Annita" <annita dot zhang at intel dot com>, "jyknight at google dot com" <jyknight at google dot com>, "tstellar at redhat dot com" <tstellar at redhat dot com>, "Lu, Hongjiu" <hongjiu dot lu at intel dot com>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 15 Jan 2020 11:21:25 -0800
- Subject: GCC 10: Add driver options -mbranches-within-32B-boundaries and -malign-branch* for x86
- Reply-to: Fāng-ruì Sòng <maskray at google dot com>
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
(https://www.intel.com/content/dam/support/us/en/documents/processors/mitigations-jump-conditional-code-erratum.pdf
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
-Wa,-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
-malign-branch-prefix-size=)[3].
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
--
宋方睿