[PATCH 0/2] x86: Fix the -mevexwig=1 assembler option

[Jan Beulich]

>>> On 16.09.18 at 14:15, <hjl.tools@gmail.com> wrote:
> 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.

I'm afraid I don't understand your request. I've already answered the
"which ones need to be fixed" part: Said commit should simply be
reverted; only the add-on commit 5be12fc1ad should stay (by these
get converted to VexWIG now anyway). And I can't make sense of the
"with a testcase" part - it's mainly up to you if and where you think a
testcase is needed (because I think existing ones already cover this).

Jan