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>
- Cc: <binutils at sourceware dot org>
- Date: Sun, 16 Sep 2018 02:48:12 -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.
Now this is exactly what I was afraid of, and what should imo absolutely not
happen anymore going forward: You introduce yet another disconnect between
i386-opc.h and i386-opc.tbl - one can't freely change the VEXWIG define without
having to touch a large number of templates. The .tbl file gets pre-processed now,
so all new attributes of non-boolean type should get added as (taking the
example here) VexWIG in the templates, with
#define VexWIG VexW=VEXWIG
somewhere earlier in the file. It is going to be yet another time consuming job
to convert all the existing instances, to correct the mistakes made here years
ago. _Then_, finally, it will be half way reasonable to read and maintain all those
templates.
Jan