[PATCH 2/6] x86: shrink some struct insn_template fields
Jan Beulich
jbeulich@suse.com
Mon Mar 29 14:49:38 GMT 2021
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.
Jan
More information about the Binutils
mailing list