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.
