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: [PATCH 0/2] x86: Fix the -mevexwig=1 assembler option


On Sun, Sep 16, 2018 at 2:38 AM, Jan Beulich <jbeulich@suse.com> wrote:
>>>> "H.J. Lu" <hjl.tools@gmail.com> 09/14/18 9:14 PM >>>
>>The VEX.W/EVEX.W bit is ignored by some VEX/EVEX instructions, aka WIG
>>instructions.  The -mevexwig=1 assembler option assumes that if the
>>vexw field of an VEX/EVEX instruction is 0, it is a WIG instruction.
>>But the vexw field of some non-WIG VEX/EVEX instructions is 0 and their
>>VEX.W/EVEX.W bit is determined by the integer register operand size.  This
>>patch set adds VEXWIG, defined as 3, to indicate that the VEX.W/EVEX.W
>>bit is ignored and set VexW=3 on VEX/EVEX WIG instructions.
>>
>>H.J. Lu (2):
>>x86: Support VEX/EVEX WIG encoding
>>x86: Check non-WIG EVEX instruction encoding with -mevexwig=1
>
> Furthermore you don't seem to correct/adjust here what you've done in commit
> 41d1ab6a6, despite me having said so right in reply to that earlier change. I
> continue to think that it would have been best to revert that commit (but not its
> amendment), adding VexWIG here as appropriate, but at the same time not
> corrupting cases where the field should indeed remain to be zero, i.e. when
> VEX.W is supposed to be determined from integer register width (i.e. REX.W).

Please take a look at users/hjl/wig branch and tell me which one needs to
fix with a testcase.

-- 
H.J.


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