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

[Richard Earnshaw (lists)]

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

 struct
    {
      bool is_reserved      : 8;
      unsigned num_regs     : 8;
      unsigned num_elements : 8;
    } data [] =

Would be just fine; on most machines that will just become byte loads anyway.

> 
>> I guess on some platforms sizeof(bool) could be larger than a char, but it's probably unusual.
> 
> It's not going to be larger than an unsigned int though, I expect. So
> still at least no loss if converted.
> 
> Jan