[PATCH] x86: drop vex_encoding_vex2 enumerator

[H.J. Lu]

On Thu, Jan 16, 2020 at 12:36 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.01.2020 23:22, H.J. Lu wrote:
> > On Tue, Jan 14, 2020 at 11:42 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> Documentation clearly says "prefer {2,3}-byte VEX prefix for VEX
> >> instruction", as opposed to "encode with EVEX prefix" for {evex}. Hence
> >> there not being a way to VEX-encode an insn should not be an error (not
> >
> > We can't prefer any VEX prefix on non AVX instructions:
> >
> > {vex} inc %rax
> >
> > should be an error.
>
> How is this in line with what the documentation states? (I
> assume you mean {vex2} in your example; I could see a future
> {vex} as being mandatory just like {evex} is. If {vex2} is
> to be mandatory, what use is it for VEX-encodable insns? The
> 2-byte form will be preferred anyway.)
>
> >> even a warning), and with this the separate enumerator becomes unneeded.
> >> (Really I'm having trouble seeing what {vex2} would be useful for when
> >> it's just a suggestion hint, not one allowing the programmer to mandate
> >> the used encoding.)
> >
> > Please keep it for now.   We are planning to use it in the future.
>
> Then may I please ask that you update the documentation to
> clarify which pseudo prefixes are hints (and silently ignored
> when they cannot be fulfilled) and which ones are mandatory?
>

How about this?

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-Update-vex2-and-vex3-documentation.patch
Type: text/x-patch
Size: 1591 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20200116/1f00cc1a/attachment.bin>