This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: processor errata vs encodings produced by gas


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

Jan



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]