[PATCH] Linux/x86: Configure gas with --enable-x86-used-note by default

[H.J. Lu]

On Thu, Jul 9, 2020 at 8:36 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.07.2020 17:22, H.J. Lu wrote:
> > On Thu, Jul 9, 2020 at 8:21 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 09.07.2020 17:02, H.J. Lu via Binutils wrote:
> >>>       * configure.ac: Configure with --enable-x86-used-note by default
> >>>       for Linux/x86.
> >>
> >> I'm quite unconvinced this is a good idea as long as the contents of
> >> these notes are neither reliable nor properly settled on what they
> >> actually mean. This should be considered an experimental feature for
> >> now, and hence would better not be enabled by default to avoid
> >> future backwards compatibility issues.
> >>
> >
> > It has been an experimental feature for 2 years.
>
> And when I asked questions about the underlying spec I did get at
> best fuzzy answers from you. I still have on my todo list to get
> this in shape with a pretty recent reply of yours, which was
> supporting my view on how things should be (and why things are
> broken right now), and hence somewhat contrary to earlier replies
> of yours.
>
> To just name the most unclear (to me) aspect of what's there
> currently: What's the distinction between xmm, ymm, and zmm, when
> zmm is a superset of ymm (and ymm one of xmm), yet at the same
> time AVX512 writes to xmm mean writes to ymm and zmm (zeroing
> upper parts) as well. From my observations e.g. an AVX512 insn
> accessing just xmm registers will record just an xmm dependency,
> which then is simply wrong - the resulting binary in fact depends
> on all of xmm, ymm, zmm, and the mask registers. IIRC I proposed
> back then to tie what an insn records to the XCR0 bits it
> requires to be set in order for it to not fault.

Should we add a field to i386 opcode table for this?

> >  Let's see what fallouts will be.
>
> Fallout may become noticeable only when the behavior of the notes
> changes: People may start noticing that new (correct) dependencies
> prevent things from working (assuming there's any consumer of
> these notes).
>

We have a couple months to address this before 2.36 is released.

-- 
H.J.