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 D82FA388450F for ; Wed, 19 Jun 2024 09:56:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D82FA388450F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D82FA388450F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718791022; cv=none; b=VRl/UDvjBadThnVLgAAOjOW2o7W8oNQ5eUN9aeeqEf/sfEi2RCtnNyGIqYPpBzLe+BgwTLpIUHv2ViJFkieyz7+wFpMNnLY0+XKgyFyUkMlEl2PZf8Dp8lhNErI7AhiRtV+3hFmrYQ01CEHS432ePPwM5eBa4NCp6EsWQF0kvLQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718791022; c=relaxed/simple; bh=MUIBTvEyGV86LxWZmsrlk+QOKQ8nGYucZ/nCDdnS3PU=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=kc/hwW6m/lrOa3FZ2a68myxCzwQvnrER2xpNiQpdvE2LJAI6HL0kd1t1nEOhfLPrQqqwnUP0FWwp/HJ4iTgHL7/3JKdi2xILRRAAAoK0+phTD2xQpwmirreCIdnmSoINQJc0ABFGhQh4+RTE5GKUgawpRbDOp7mf8T4SyBb4PQo= ARC-Authentication-Results: i=1; server2.sourceware.org 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 393E4DA7; Wed, 19 Jun 2024 02:57:24 -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 636B43F64C; Wed, 19 Jun 2024 02:56:58 -0700 (PDT) From: Richard Sandiford To: Ajit Agarwal Mail-Followup-To: Ajit Agarwal ,Alex Coplan , "Kewen.Lin" , Segher Boessenkool , Michael Meissner , Peter Bergner , David Edelsohn , gcc-patches , richard.sandiford@arm.com Cc: Alex Coplan , "Kewen.Lin" , Segher Boessenkool , Michael Meissner , Peter Bergner , David Edelsohn , gcc-patches Subject: Re: [Patch, rs6000, middle-end] v2: Add implementation for different targets for pair mem fusion References: <870719f4-0923-497d-bba2-c83e46a4b13a@linux.ibm.com> <43657e9f-91f9-426d-8bef-05b78755995f@linux.ibm.com> <04443b0c-3cd4-4110-97bc-a41cc68f7b8d@linux.ibm.com> <5c18677d-919a-4450-8706-09d83c133fec@linux.ibm.com> Date: Wed, 19 Jun 2024 10:56:57 +0100 In-Reply-To: <5c18677d-919a-4450-8706-09d83c133fec@linux.ibm.com> (Ajit Agarwal's message of "Wed, 19 Jun 2024 15:09:20 +0530") 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=-13.8 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Ajit Agarwal writes: > On 19/06/24 2:52 pm, Richard Sandiford wrote: >> Ajit Agarwal writes: >>> On 19/06/24 2:40 pm, Richard Sandiford wrote: >>>> Ajit Agarwal writes: >>>>> Hello Richard: >>>>> >>>>> On 19/06/24 1:54 pm, Richard Sandiford wrote: >>>>>> Ajit Agarwal writes: >>>>>>>> What happens if you leave the assert alone? When does it fire? Is it >>>>>>>> still for uses in debug insns? If so, it's the fusion pass's responsibility >>>>>>>> to update those, as mentioned above. And it must update them before, >>>>>>>> or at the same time as, it deletes the definition. >>>>>>>> >>>>>>> >>>>>>> For debug insn I call reset_debug_use and now I dont see issues >>>>>>> with debug insn and issues I see with non debug insn where >>>>>>> def is there in old_defs and use has to be removed for the insn >>>>>>> that we modify load with OO UNSPEC to generate lxvp. >>>>>> >>>>>> Can you walk me through it step-by-step? If you leave the assert >>>>>> alone, when does it fire? What set of insn_changes are being made >>>>>> when the assert fires? (Calling debug on the changes will show this.) >>>>>> And what use does the assert fire on? (Again, calling debug on the use >>>>>> will show this.) >>>>>> >>>>> >>>>> (insn 660 735 739 50 (set (reg:OO 405 [ MEM[(_Float128 *)src_196] ]) >>>>> (unspec:OO [ >>>>> (mem:OO (reg/v/f:DI 197 [ base ]) [9 MEM[(_Float128 *)src_196]+0 S16 A128]) >>>>> ] UNSPEC_LXVP)) 2188 {*movoo1} >>>>> (nil)) >>>>> >>>>> This is definition. >>>>> >>>>> (insn 661 659 662 50 (set (reg:TF 179 [ result$imag ]) >>>>> (plus:TF (reg:TF 179 [ result$imag ]) >>>>> (subreg:TF (reg:OO 405 [ MEM[(_Float128 *)src_196] ]) 0))) {addtf3} >>>>> >>>>> This is use. >>>>> >>>>> change has the above definition and the assert fires at the >>>>> above use. >>>> >>>> But can you call debug on the insn_change that contains the deleted def, >>>> and call debug on the access_info that triggers the assert? >>>> >>> >>> I am afraid I am not getting what exactly you meant here. >> >> One way would be to apply a patch like the below and quote the >> output from the last "Changes:" onward. >> >> Richard >> > > Thanks. > > This is the dump of use at assert point. > > use of superceded set r178:i131 (V2DI pseudo) by insn i133 in bb2 [ebb2] at point 180 > defined in bb2 [ebb2] at point 108 > > This is the dump of change. > > deletion of insn i130 in bb2 [ebb2] at point 106: > deleted > uses: > use of set r219:i291 (DI pseudo) > appears inside an address > superceded use of set mem:i114 > defines: > set r177:i131 (OO pseudo) > used by insn i132 in bb2 [ebb2] at point 178 > change to insn i131 in bb2 [ebb2] at point 108: > +-------------------------------------- > | 131: r177:OO=unspec[[r219:DI]] 101 > +-------------------------------------- > uses: > superceded use of set r219:i291 (DI pseudo) > appears inside an address > superceded use of set mem:i114 > defines: > superceded set r178:i131 (V2DI pseudo) > used by insn i133 in bb2 [ebb2] at point 180 > ~~~~~~~ > new cost: 2147483647 > new uses: > use of set r219:i291 (DI pseudo) by insn i131 in bb2 [ebb2] at point 108 > defined in bb2 [ebb2] at point 62 > appears inside an address > use of set mem:i114 by insn i131 in bb2 [ebb2] at point 108 > defined in bb2 [ebb2] at point 104 > new defs: > set r177:i131 (OO pseudo) in bb2 [ebb2] at point 108 > used by insn i132 in bb2 [ebb2] at point 178 > first insert-after candidate: insn i131 in bb2 [ebb2] at point 108 > last insert-after candidate: insn i131 in bb2 [ebb2] at point 108 Thanks. It looks like you're updating just the definitions, and then later updating the uses. That isn't the way that rtl-ssa is supposed to be used. Each change set -- in other words, each call to function_info::change_insns -- must go from a valid state to a valid state. That is, the RTL must be self-consistent before every individual call to function_info::change_insns and must be self-consistent after every individual call to function_info::change_insns. This is what I meant before about: ... if we're removing a definition, all uses in "real" debug and non-debug insns must be removed either earlier than the definition or at the same time as the definition. No such uses should remain. Since you want to update all uses of register 178, you need to include those updates in the same change set as the change to insns 130 and 131, rather than doing them later. Richard