[PATCH] x86: Properly set YMM/ZMM features

[H.J. Lu]

On Thu, Jul 9, 2020 at 9:17 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 9:13 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 09.07.2020 17:44, H.J. Lu wrote:
> > > 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?
> >
> > I was wanting to try without, to see how much logic would be needed.
> > If it gets too much, doing so may be the better choice.
>
> I am checking in this patch.

Here is the right patch.

> > >>>  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.
> >
> > Under the assumption that people test non-released code ...
> >
>
> We will see.
>
>
> --
> H.J.



-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-Properly-set-YMM-ZMM-features.patch
Type: text/x-patch
Size: 5998 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20200709/1f23cb4f/attachment.bin>