On Wed, 15 Jan 2020, Fāng-ruì Sòng wrote: > 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
A x86 specific option handling it via specs processing is up to the decision of the architecture maintainers. Richard.
