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


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


Jan



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