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 -- 宋方睿
