This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
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.