[PATCH] opcodes/aarch64: make aarch64_ext_ldst_reglist()'s data[] static const

[Jan Beulich]

On 29.07.2025 10:57, Richard Earnshaw (lists) wrote:
> On 29/07/2025 07:53, Jan Beulich wrote:
>> On 28.07.2025 18:10, Richard Earnshaw (lists) wrote:
>>> On 28/07/2025 16:58, Jan Beulich wrote:
>>>> ---
>>>> I further wonder whether the struct fields being unsigned int isn't
>>>> wasteful - unsigned char (or bool for "is_reserved") would appear to
>>>> suffice, without negatively affecting generated code (except on
>>>> architectures where byte loads are more expensive).
>>>
>>> uint8_t would be fine and preferable to (unsigned) char since it's a value not a character.
>>
>> I can use uint8_t, but personally I recommend to avoid fixed-width types
>> where they can be avoided. They will only cause problems on architectures
>> which have no way to express those types. (E.g. on TI C4x and C54x I
>> wonder how uint8_t would be expressable, with them having 32 / 16 bits
>> per byte respectively.) The "not a character" argument imo only applies
>> to uses of plain char; signed or unsigned forms thereof are normal (just
>> narrow) integer types according to my understanding).
> 
> If space is a concern then I'd just use a bitfield.  Performance isn't critical here, so

Okay, if bitfields are okay to use here, I'd indeed prefer going that route.

>  struct
>     {
>       bool is_reserved      : 8;

I don't think a bool bitfield can be other than 1 bit wide, though. I'd put
the field ...

>       unsigned num_regs     : 8;
>       unsigned num_elements : 8;

... last then.

>     } data [] =
> 
> Would be just fine; on most machines that will just become byte loads anyway.

Indeed.

Jan