[PATCH 7/8] x86: derive mandatory prefix attribute from base opcode

[Jan Beulich]

On 23.03.2021 19:34, H.J. Lu wrote:
> On Tue, Mar 23, 2021 at 9:36 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 22.03.2021 19:03, H.J. Lu wrote:
>>> On Mon, Mar 22, 2021 at 05:46:14PM +0100, Jan Beulich wrote:
>>>> Just like is already done for legacy encoded insns, record the mandatory
>>>> prefix information in the respective opcode modifier field. Do this
>>>> without changing the source table, but rather by deriving the values from
>>>> their existing source representation.
>>>>
>>>> gas/
>>>> 2021-03-XX  Jan Beulich  <jbeulich@suse.com>
>>>>
>>>>      * config/tc-i386.c (md_begin): Add assertion.
>>>>      (build_vex_prefix): Drop implied prefix calculation.
>>>>      (build_evex_prefix): Likewise.
>>>>      (optimize_encoding): Adjust opcode checks.
>>>>      (load_insn_p): Also check opcodeprefix.
>>>>      (match_template): Also check opcodespace.
>>>>      (process_suffix): Likewise.
>>>>      (process_operands): Likewise.
>>>>      (output_insn): Likewise. Also check isprefix when discaring
>>>>      standalone LOCK.
>>>>      * config/tc-i386-intel.c (i386_intel_operand): Also check
>>>>      opcodespace.
>>>>
>>>> opcodes/
>>>> 2021-03-XX  Jan Beulich  <jbeulich@suse.com>
>>>>
>>>>      * i386-gen.c (process_i386_opcode_modifier): Return void. New
>>>>      parameter "prefix". Drop local variable "regular_encoding".
>>>>      Record prefix setting / check for consistency.
>>>>      (output_i386_opcode): Parse opcode_length and base_opcode
>>>>      earlier. Derive prefix encoding. Drop no longer applicable
>>>>      consistency checking. Adjust process_i386_opcode_modifier()
>>>>      invocation.
>>>>      (process_i386_opcodes): Adjust process_i386_opcode_modifier()
>>>>      invocation.
>>>>      * i386-tbl.h: Re-generate.
>>>
>>> OK.  Thanks.
>>
>> Thanks. Just to confirm - you being okay with the approach here, are
>> also okay with the outlined (in a post commit message remark) further
>> planned course of action?
> 
> Sounds good to me.  But I need to see the actual patch for sure.

Well, there are multiple steps. The first one, to extract 0f etc
"prefixes" from the opcodes, is less likely to be controversial.
Reverting the PREFIX_0X<nn> uses on legacy encoded opcodes is
likely to rank in the middle, while moving encoding space
specification to the actual opcodes for VEX/XOP/EVEX templates is
likely the most questionable one, not the least because of the
need to "invent" a representation for XOP (I'm considering to use
8f0[89a] as a prefix, but I can also see alternatives).

Jan