Re: processor errata vs encodings produced by gas

["Jan Beulich" <JBeulich at suse dot com>]

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

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

Jan