From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id CE1BF3858401 for ; Wed, 23 Aug 2023 16:18:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CE1BF3858401 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 14F9A1042; Wed, 23 Aug 2023 09:18:43 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E78233F740; Wed, 23 Aug 2023 09:18:01 -0700 (PDT) From: Richard Sandiford To: "Richard Earnshaw \(lists\)" Mail-Followup-To: "Richard Earnshaw \(lists\)" ,Richard Earnshaw via Gcc-patches , Richard Earnshaw , richard.sandiford@arm.com Cc: Richard Earnshaw via Gcc-patches , Richard Earnshaw Subject: Re: [PATCH] rtl: Forward declare rtx_code References: <20230822120219.3997652-1-rearnsha@arm.com> <5af7042f-d387-f6ea-8d0c-63180bf85724@arm.com> Date: Wed, 23 Aug 2023 17:18:00 +0100 In-Reply-To: <5af7042f-d387-f6ea-8d0c-63180bf85724@arm.com> (Richard Earnshaw's message of "Wed, 23 Aug 2023 17:11:57 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-25.5 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: "Richard Earnshaw (lists)" writes: > On 23/08/2023 16:49, Richard Sandiford via Gcc-patches wrote: >> Richard Earnshaw via Gcc-patches writes: >>> Now that we require C++ 11, we can safely forward declare rtx_code >>> so that we can use it in target hooks. >>> >>> gcc/ChangeLog >>> * coretypes.h (rtx_code): Add forward declaration. >>> * rtl.h (rtx_code): Make compatible with forward declaration. >>> --- >>> gcc/coretypes.h | 4 ++++ >>> gcc/rtl.h | 2 +- >>> 2 files changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/gcc/coretypes.h b/gcc/coretypes.h >>> index ca8837cef67..51e55559ce0 100644 >>> --- a/gcc/coretypes.h >>> +++ b/gcc/coretypes.h >>> @@ -100,6 +100,10 @@ struct gimple; >>> typedef gimple *gimple_seq; >>> struct gimple_stmt_iterator; >>> >>> +/* Forward declare rtx_code, so that we can use it in target hooks without >>> + needing to pull in rtl.h. */ >>> +enum rtx_code : unsigned; >>> + >>> /* Forward decls for leaf gimple subclasses (for individual gimple codes). >>> Keep this in the same order as the corresponding codes in gimple.def. */ >>> >>> diff --git a/gcc/rtl.h b/gcc/rtl.h >>> index e1c51156f90..0e9491b89b4 100644 >>> --- a/gcc/rtl.h >>> +++ b/gcc/rtl.h >>> @@ -45,7 +45,7 @@ class predefined_function_abi; >>> /* Register Transfer Language EXPRESSIONS CODES */ >>> >>> #define RTX_CODE enum rtx_code >>> -enum rtx_code { >>> +enum rtx_code : unsigned { >>> >>> #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS) ENUM , >>> #include "rtl.def" /* rtl expressions are documented here */ >> >> Given: >> >> #define RTX_CODE_BITSIZE 8 >> >> there might be some value in making it uint8_t rather than unsigned. >> Preapproved if you agree. >> >> But the patch as posted is a strict improvement over the status quo, >> so it's also OK as-is. >> >> Thanks, >> Richard > > I did think about that, but there were two reasons for not doing so: > - it presumes we would never want more than 8 bits for rtx_code (well, not quite, > but it would make it more work to change this). The rtx_def structure itself provides a significant barrier to that though. If we ever think that we need to represent more than 256 separate operations, I think the natural way would be to treat the less well-used ones in a similar way to unspecs. > - it would probably lead to more zero-extension operations happening in the compiler Yeah, that's true. The upside though is that we could then declare arrays of codes directly, without having to resort to "unsigned char" tricks. That's unlikely to help codes much, but the same principle would apply to modes, which are more frequently put into arrays. E.g. one of the issues with bumping the machine_mode bitfield from 8 to 16 bits was finding all the places where "unsigned char" was used to hold modes, and changing them to "unsigned short". If machine_mode was instead the "right" size, we could just call a spade a spade. But like I say, that's mostly reasoning by analogy rather than because the size of rtx_code itself is important. Richard