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 62FA5385740F for ; Mon, 10 May 2021 14:54:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 62FA5385740F 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 0E8D91691; Mon, 10 May 2021 07:54:48 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8D3B93F719; Mon, 10 May 2021 07:54:47 -0700 (PDT) From: Richard Sandiford To: Wilco Dijkstra Mail-Followup-To: Wilco Dijkstra , Wilco Dijkstra via Gcc-patches , richard.sandiford@arm.com Cc: Wilco Dijkstra via Gcc-patches Subject: Re: [PATCH] AArch64: Improve GOT addressing References: Date: Mon, 10 May 2021 15:54:46 +0100 In-Reply-To: (Wilco Dijkstra's message of "Mon, 10 May 2021 15:04:47 +0100") 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=-6.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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, 10 May 2021 14:54:49 -0000 Wilco Dijkstra writes: > Hi Richard, > >> Normally we should only put two instructions in the same define_insn >> if there's a specific ABI or architectural reason for not separating >> them. Doing it purely for optimisation reasons is going against the >> general direction of travel. So I think the first question is: why >> don't we simply delay the split until after reload instead, since >> that's the more normal way of handling this kind of thing? > > Well there are no optimizations that benefit from them being split, and there > is no gain from scheduling them independently. Keeping them together > means the linker could perform relaxations on the pair without adding new > relocations. So if we split after reload we'd still want to keep them together. The burden of proof is the other way though: there has to be a specific reason for keeping the instructions together, rather than a specific reason for splitting them. How we optimise things after RA changes with time. Thanks, Richard