[PATCH 2/6] x86: shrink some struct insn_template fields

[H.J. Lu]

On Mon, Mar 29, 2021 at 7:49 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 29.03.2021 16:41, H.J. Lu wrote:
> > On Mon, Mar 29, 2021 at 7:03 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 29.03.2021 15:00, H.J. Lu wrote:
> >>> On Fri, Mar 26, 2021 at 3:50 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> Now that all base opcodes are only at most 2 bytes in size, shrink its
> >>>> template field to just as much. By also shrinking extension_opcode and
> >>>> operands to just what they really need, we can free up an entire 32-bit
> >>>> slot (plus 4 left bits past the bitfields themselves).
> >>>>
> >>>> At present this alters sizeof(struct insn_template) only for 32-bit
> >>>> builds. In 64-bit builds it instead leaves a padding hole that will
> >>>> allow to buffer future growth of other fields (opcode_modifier,
> >>>> cpu_flags, operand_types[]).
> >>>>
> >>>> opcodes/
> >>>> 2021-03-XX  Jan Beulich  <jbeulich@suse.com>
> >>>>
> >>>>         * i386-opc.h (struct insn_template): Shrink base_opcode to 16
> >>>>         bits. Shrink extension_opcode to 9 bits. Make it signed. Change
> >>>>         value of None. Shrink operands to 3 bits.
> >>>> ---
> >>>> Code-generation wise it may be better to move the signed
> >>>> extension_opcode field last within the containing 32-bit slot.
> >>>
> >>> extension_opcode should be next to opcode in template.
> >>
> >> In the source table, in the binary representation, or both? (I certainly
> >> agree they should be next to each other in the source table.)
> >
> > Only in the source code, not in the binary representation.
>
> Yet the remark was about the (positive) code gen effects changing the
> binary representation was likely to have. I then understand you wouldn't
> object to moving this field.
>

Correct.

-- 
H.J.