This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 0/5] i386: Optimize for Jump Conditional Code Erratum
On Tue, Dec 3, 2019 at 4:01 PM Jeff Law <email@example.com> wrote:
> 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.
I can certainly add an option to make it the default. It can be
turned off with