processor errata vs encodings produced by gas

[H.J. Lu]

On Fri, Dec 21, 2018 at 1:02 AM Jan Beulich <JBeulich@suse.com> wrote:
>
> >>> On 20.12.18 at 18:42, <hjl.tools@gmail.com> wrote:
> > On Wed, Dec 19, 2018 at 11:40 PM Jan Beulich <JBeulich@suse.com> wrote:
> >>
> >> >>> On 19.12.18 at 18:27, <hjl.tools@gmail.com> wrote:
> >> > On Wed, Dec 19, 2018 at 8:59 AM Jan Beulich <JBeulich@suse.com> wrote:
> >> >>
> >> >> Hi H.J.,
> >> >>
> >> >> having had to deal with such SandyBridge errata (BT36, BT41, and
> >> >> BT230) in a different context, it occurred to me that it's not ideal
> >> >> for gas to (allow to) produce such encodings in the first place. The
> >> >> problem has been there virtually forever for VCVT{,T}S{S,D}2SI
> >> >
> >> > True.
> >> >
> >> >> and the use of -mavxscalar=256, but our combined recent effort
> >> >> to improve VEX.W handling has extended it to VZERO{ALL,UPPER}
> >> >> and (in the 32-bit case) VPEXTRD when of using -mvexwig=1.
> >> >>
> >> >> These are errata, so I'm not suggesting to revert what has been
> >> >> done. Instead I'm trying to think of ways to point out the issue
> >> >> to the programmer and/or default to safe encodings but still allow
> >> >> a means to override them. One question of course is what the
> >> >> target audience for options like -mavxscalar= was meant to be,
> >> >
> >> > They are used to generate different encodings to test disassembler.
> >>
> >> So flagging them (in documentation) as "don't use for generating
> >> production code" would be enough - are you fine with just doing
> >> that?
> >
> > If we fix i386-opc.tbl so that -mavxscalar= works everywhere,
> > do we still need it?
>
> That would be an effective revert, which is what I've explicitly
> said I'd prefer to avoid. Furthermore it would undermine your
> primary goal of having the option: Being able to "generate
> different encodings to test disassembler", as is still visible from
> your earlier reply in context above.
>
> >> >> when these options got introduced. Hence a variant of the first
> >> >> approach could be to simply flag use of these options as
> >> >> "dangerous" (and hence a suggestion to not use them for building
> >> >> production code).
> >> >>
> >> >> As to -mavxscalar=256 in particular, the SDM now recommends
> >> >> to set VEX.L to zero for all scalar insns.
> >> >
> >> > We need to properly mark all instructions, including errata, with WIG.
> >>
> >> I'm afraid this is ambiguous to me: "Properly" might mean "according
> >> to the SDM" or "according to what actually works everywhere".
> >> Would you mind clarifying?
> >
> > According to what actually works everywhere with comments in
> > i386-opc.tbl explaining why we differs from SDM.
>
> This would then bring us back to the situation where one needs to
> use .byte to produce certain encodings. I don't like this. How about
> a 3rd avxscalar mode, e.g. vex256force? The current vex256 mode
> would apply to errata-free insns, while the forced one would apply
> to ones with an associated erratum. Same then for vexwig.
>
> That said, personally I'd still prefer simply documenting use of the
> options as potentially dangerous.

Fine with me.  Please document it as dangerous and explain why

Thanks.

-- 
H.J.