From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from arjuna.pair.com (arjuna.pair.com [209.68.5.131]) by sourceware.org (Postfix) with ESMTPS id 710F33858404 for ; Fri, 31 Mar 2023 00:01:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 710F33858404 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=bitrange.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=bitrange.com Received: by arjuna.pair.com (Postfix, from userid 3006) id E04778A71D; Thu, 30 Mar 2023 20:01:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by arjuna.pair.com (Postfix) with ESMTP id DF5858A701; Thu, 30 Mar 2023 20:01:23 -0400 (EDT) Date: Thu, 30 Mar 2023 20:01:23 -0400 (EDT) From: Hans-Peter Nilsson X-X-Sender: hp@arjuna.pair.com To: Peter Bergner cc: Jeff Law , Ajit Agarwal , gcc-patches , Segher Boessenkool , Richard Biener , Raphael Zinsly Subject: Re: [PATCH] rtl-optimization: ppc backend generates unnecessary signed extension. In-Reply-To: <0caf5e53-76e2-afc6-8b8c-363e56cd8212@linux.ibm.com> Message-ID: References: <4c0b6b4f-bbc1-8dd0-a91c-ffed028b4873@linux.ibm.com> <365cfb50-4313-d44e-6ffc-77473b20c670@linux.ibm.com> <5834b0cb-dd25-c55f-2cf6-9aa6b8372724@linux.ibm.com> <29ab8ff7-20d5-183f-a0ce-c82758488b64@linux.ibm.com> <1a482ac5-404b-0787-c682-b10d13dc76ee@gmail.com> <247f5af3-5db3-4a73-b636-95e006a3a649@linux.ibm.com> <0caf5e53-76e2-afc6-8b8c-363e56cd8212@linux.ibm.com> User-Agent: Alpine 2.20.16 (BSF 172 2016-09-29) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: mailmunge 3.11 on 209.68.5.131 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,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: On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote: > On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote: > >>>> Is there a reason why REE cannot see that our (reg:QI 4) is a param register > >>>> and thus due to our ABI, already correctly sign/zero extended? > >>> > >>> I don't think REE has ever considered exploiting ABI constraints. Handling > >>> that might be a notable improvement on various targets. It'd be a great > >>> place to do some experimentation. > >> > >> Ok, so sounds like a good follow-on project after this patch is reviewed > >> and committed (stage1). Thanks for your input! > > > > Agreed. I suspect that risc-v will benefit from such work as well. > > With that in mind, if y'all start poking at this, please loop in Raphael > > (on cc) who's expressed an interest in this space. > > Will do. I suspect that it'll be best to come up with some generic interface > using target hooks like "param regs are sign/zero extended" or "call return > values are sign/zero extended", etc. that targets can conditionally opt into > depending on their ABI that is in effect. Pardon the arm-chair development mode but it sounds like re-inventing the TARGET_PROMOTE_* hooks... Maybe just hook up TARGET_PROMOTE_FUNCTION_MODE to ree.c (as "you" already already define it for "rs6000")? brgds, H-P