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.

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





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