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
- From: "Jan Beulich" <jbeulich at suse dot com>
- To: <hjl dot tools at gmail dot com>,<binutils at sourceware dot org>
- Date: Sun, 16 Sep 2018 03:38:40 -0600
- Subject: Re: [PATCH 0/2] x86: Fix the -mevexwig=1 assembler option
- References: <20180914191434.26422-1-hjl.tools@gmail.com>
>>> "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