From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 47D2E385841C; Wed, 14 Jun 2023 15:06:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 47D2E385841C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 35EF58E8007181; Wed, 14 Jun 2023 10:05:08 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 35EF57hc007180; Wed, 14 Jun 2023 10:05:07 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 14 Jun 2023 10:05:07 -0500 From: Segher Boessenkool To: Xi Ruoyao Cc: Jiufu Guo , gcc-patches@gcc.gnu.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, bergner@linux.ibm.com, rguenther@suse.de, richard.sandiford@arm.com, jeffreyalaw@gmail.com Subject: Re: [PATCH] rs6000: replace '(const_int 0)' to 'unspec:BLK [(const_int 0)]' for stack_tie Message-ID: <20230614150507.GV19790@gate.crashing.org> References: <20230613122335.2108620-1-guojiufu@linux.ibm.com> <7nfs6ubyel.fsf@ltcden2-lp1.aus.stglabs.ibm.com> <6bd54083cadc5d5720afb01f9ab202a2ac748863.camel@xry111.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6bd54083cadc5d5720afb01f9ab202a2ac748863.camel@xry111.site> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi! On Wed, Jun 14, 2023 at 05:18:15PM +0800, Xi Ruoyao wrote: > The generic issue here is to fix (not "papering over") the signed > overflow, we need to perform the addition in a target machine mode. We > may always use Pmode (IIRC const_anchor was introduced for optimizing > some constant addresses), but can we do better? The main issue is that the machine description generated target code to compute some constants, but the sanitizer treats it as if it was user code that might do wrong things. > Should we try addition in both DImode and SImode for a 64-bit capable > machine? Why? At least on PowerPC there is only one insn, and it is 64 bits. The SImode version just ignores all bits other than the low 32 bits, in both inputs and output. > Or should we even try more operations than addition (for eg bit > operations like xor or shift)? Doing so will need to create a new > target hook for const anchoring, this is the "complete rework" I meant. This might make const anchor useful for way more targets maybe, including rs6000, yes :-) Segher