processor errata vs encodings produced by gas

[H.J. Lu]

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.

> 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.

Thanks.

-- 
H.J.