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 8FB433858C50 for ; Mon, 16 May 2022 11:36:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8FB433858C50 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 2A7B01063; Mon, 16 May 2022 04:36:24 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.37]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 50DEF3F66F; Mon, 16 May 2022 04:36:23 -0700 (PDT) From: Richard Sandiford To: Tamar Christina Mail-Followup-To: Tamar Christina , gcc-patches@gcc.gnu.org, nd@arm.com, rguenther@suse.de, jeffreyalaw@gmail.com, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, nd@arm.com, rguenther@suse.de, jeffreyalaw@gmail.com Subject: Re: [PATCH 1/3]middle-end: Add the ability to let the target decide the method of argument promotions. References: Date: Mon, 16 May 2022 12:36:22 +0100 In-Reply-To: (Tamar Christina's message of "Fri, 13 May 2022 18:11:12 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2022 11:36:26 -0000 Tamar Christina writes: > Hi All, > > Some targets require function parameters to be promoted to a different > type on expand time because the target may not have native instructions > to work on such types. As an example the AArch64 port does not have nati= ve > instructions working on integer 8- or 16-bit values. As such it promotes > every parameter of these types to 32-bits. This doesn't seem specific to parameters though. It applies to any 8- or 16-bit variable. E.g.: #include uint8_t foo(uint32_t x, uint32_t y) { uint8_t z =3D x !=3D 0 ? x : y; return z + 1; } generates: foo: cmp w0, 0 and w1, w1, 255 and w0, w0, 255 csel w0, w1, w0, eq add w0, w0, 1 ret So I think the new behaviour is really a modification of the PROMOTE_MODE behaviour rather than the PROMOTE_FUNCTION_MODE behaviour. FWIW, I agree with Richard that it would be better not to add a new hook. I think we're really making PROMOTE_MODE choose between SIGN_EXTEND, ZERO_EXTEND or SUBREG (what LLVM would call =E2=80=9Cany extend=E2=80=9D) r= ather than the current SIGN_EXTEND vs. ZERO_EXTEND choice. Thanks, Richard