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

[H.J. Lu]

On Wed, Mar 24, 2021 at 12:27 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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).
>

We will see how it works out.

-- 
H.J.