Re: Adjust LTO mode tables for "Machine_Mode: Extend machine_mode from 8 to 16 bits" (was: [PATCH] Machine_Mode: Extend machine_mode from 8 to 16 bits)

[Thomas Schwinge <thomas@codesourcery.com>]

Hi Jakub!

On 2023-06-30T18:37:59+0200, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Jun 30, 2023 at 08:45:38PM +0800, Kito Cheng wrote:
>> Hmmm, I think maybe what we need is to leverage C++ language features
>> to declare enum with underlying types like that:
>>
>> enum machine_mode : uint16_t
>
> What would be the advantage of doing that?
> I mean, on most hosts using unsigned rather than unsigned short is
> actually faster

Interesting, I had not considered that, and assumed we'd always
space-optimize such things.  But yes, I do see your point.

Is it worth adding some such rationale into a new "Data Types" (or
similar) section on <https://gcc.gnu.org/codingconventions.html>,
<https://gcc.gnu.org/codingrationale.html>?

> and for the cases where we care about the size
> (e.g. mode in RTL, DECLs and the like) we already use enum bitfields.

So, which category does (current) 'unsigned char *mode_table' in
'gcc/lto-streamer.h:struct lto_file_decl_data' fall into?  Used in
'gcc/tree-streamer.h:bp_unpack_machine_mode', normally (non-offloading
case) doing "identity-lookup" via
'gcc/lto/lto-common.cc:lto_mode_identity_table'.  Should this turn into
'ENUM_BITFIELD (machine_mode)' ("native size") or
'ENUM_BITFIELD (machine_mode) : MACHINE_MODE_BITSIZE' (space-optimized)?


Grüße
 Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955