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 0A3C33858431 for ; Mon, 22 Jan 2024 16:06:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A3C33858431 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 0A3C33858431 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=1705939565; cv=none; b=UMIHvROSgstDkVcxAHW7bg5oQ5yokR5WueYImm0C7ZsWWgkK2qUVnWHVrbTlQhJetBglERRlzqaCxtCY8POgfUnx1AMpwn4WXMdMuxts9o/cZXOEyZrZ6SmRgmOcL0WqRkn4sSFKOPv+69sr18R8NsVVrgALLH4cYUFna/LT4jc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705939565; c=relaxed/simple; bh=pagAeZnUm4nucEfI/T7WRPIIr48WGYbn4xarASrpAvk=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=cllyR9MPtNnhv1j0x9i1X2LPJ9EcHJZO832YGVzMkermBLYJmYsFsg7+fQF6MhTikfgoXp4Ih8ilDz+LcMPoKPUDEgC4KwqqAbQViqZkrVanBIpXwyZcY1pTe1I7HwJjpFOayRtBz6k/Pjj66VR3ZBI8STeBP+gPDll4GPyOP/w= 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 D0FC81FB; Mon, 22 Jan 2024 08:06:47 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0DA983F5A1; Mon, 22 Jan 2024 08:06:00 -0800 (PST) From: Richard Sandiford To: Alex Coplan Mail-Followup-To: Alex Coplan ,gcc-patches@gcc.gnu.org, Richard Earnshaw , Kyrylo Tkachov , richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, Richard Earnshaw , Kyrylo Tkachov Subject: Re: [PATCH] aarch64: Don't record hazards against paired insns [PR113356] References: Date: Mon, 22 Jan 2024 16:05:59 +0000 In-Reply-To: (Alex Coplan's message of "Mon, 15 Jan 2024 14:26:02 +0000") 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=-15.4 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,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: Alex Coplan writes: > Hi, > > For the testcase in the PR, we try to pair insns where the first has > writeback and the second uses the updated base register. This causes us > to record a hazard against the second insn, thus narrowing the move > range away from the end of the BB. > > However, it isn't meaningful to record hazards against the other insn > in the pair, as this doesn't change which pairs can be formed, and also > doesn't change where the pair is formed (from the perspective of > nondebug insns). > > To see why this is the case, consider the two cases: > > - Suppoe we are finding hazards for insns[0]. If we record a hazard > against insns[1], then range.last becomes > insns[1]->prev_nondebug_insn (), but note that this is equivalent to > inserting after insns[1] (since insns[1] is being changed). > - Now consider finding hazards for insns[1]. Suppose we record > insns[0] as a hazard. Then we set range.first = insns[0], which is a > no-op. > > As such, it seems better to never record hazards against the other insn > in the pair, as we check whether the insns themselves are suitable for > combination separately (e.g. for ldp checking that they use distinct > transfer registers). Avoiding unnecessarily narrowing the move range > avoids unnecessarily re-ordering over debug insns. > > This should also mean that we can only narrow the move range away from > the end of the BB in the case that we record a hazard for insns[0] > against insns[1]->prev_nondebug_insn () or earlier. This means that for > the non-call-exceptions case, either the move range includes insns[1], > or we reject the pair (thus the assert tripped in the PR should always > hold). > > Bootstrapped/regtested on aarch64-linux-gnu with/without ldp passes > enabled on top of the PR113070 fixes, OK for trunk? > > Thanks, > Alex > > gcc/ChangeLog: > > PR target/113356 > * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::try_fuse_pair): > Don't record hazards against the opposite insn in the pair. > > gcc/testsuite/ChangeLog: > > PR target/113356 > * gcc.target/aarch64/pr113356.C: New test. OK, thanks. Richard