This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/5] i386: Optimize for Jump Conditional Code Erratum

On 12/3/19 1:19 PM, H.J. Lu wrote:
>> 4. Shall we default to -mbranches-within-32B-boundaries if the specified
>>    -march= or -mtune= may be affected by the erratum?
> No. It’s a performance mitigation for the microcode update not a
> functional fix. While it can mitigate the potential performance effect
> in most cases as we observed, it increases the code size and may harm
> the performance in some cases. It may also impact the performance of
> those architectures which are not affected by this JCC erratum.
> Software mitigation cannot be applied in some scenarios where
> application behavior is dependent on exact code size. In other words,
> the inserted padding (prefix, nop) may break the assumption of code
> size that the programmer has made.  We have observed such assumptions
> in the compilation of the Linux kernel.
ISTM those cases (like the kernel startup code) could/should opt-opt,
possibly at the file level since IIRC it's just one assembly file where
the sizes of jumps are supposed to be fixed.

> Therefore we do not enable it by default. The user should evaluate its
> impact and make their own determination as to whether to enable the
> software mitigation  knowing that when this option is enabled, the
> performance impact may vary case-by-case.
The problem with not enabling it by default is a distro would have to
inject the flag into their builds.  It's not uncommon for injection
mechanisms to not work on packages like gcc, glibc, etc.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]