This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: processor errata vs encodings produced by gas
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at suse dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 19 Dec 2018 09:27:03 -0800
- Subject: Re: processor errata vs encodings produced by gas
- References: <5C1A78F20200007800207B6F@prv1-mh.provo.novell.com>
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.