processor errata vs encodings produced by gas

[Jan Beulich]

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

Jan