Hi Jakub! On 2023-06-30T18:37:59+0200, Jakub Jelinek <ja...@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
