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 ED6783836001 for ; Thu, 10 Jun 2021 21:35:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED6783836001 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail 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 15ALYJLb016666; Thu, 10 Jun 2021 16:34:19 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 15ALYIL6016665; Thu, 10 Jun 2021 16:34:18 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 10 Jun 2021 16:34:18 -0500 From: Segher Boessenkool To: Peter Bergner Cc: Jeff Law , GCC Patches , Michael Meissner Subject: Re: Aligning stack offsets for spills Message-ID: <20210610213418.GP18427@gate.crashing.org> References: <98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com> <960271b1-f8e5-48a1-576a-e655babd4e32@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <960271b1-f8e5-48a1-576a-e655babd4e32@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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: Thu, 10 Jun 2021 21:35:22 -0000 On Thu, Jun 10, 2021 at 02:28:34PM -0500, Peter Bergner via Gcc-patches wrote: > On 6/7/21 2:00 PM, Jeff Law wrote: > > I can't divulge many of the details right now, but one of the quirks of our > > architecture is that reg+d addressing modes for our vector loads/stores require > > the displacement to be aligned. This is an artifact of how these instructions > > are encoded. > > Given what you're describing, it sounds like POWER has something similar. > Our reg+displacement addressing uses 16-bit displacements using D, DS or DQ > operand fields. The D field encodes the entire 16-bits, but the DS and DQ > fields only encode 14-bits and 12-bits respectively. Yes, the low 2 resp. 4 bits of the offset are used for other things in the instruction encoding for DS and DQ. > The DS and DQ operands > have the same maximum displacement as D operands, we just force that their > bottom 2-bits/4-bits must be zero, so we don't need to include them in the > insn encoding. I believe this is all just handled in our legitimate address > routines, but maybe Segher and/or Mike can correct me if I'm wrong? This is all correct. But probably the main thing is that our ABIs require most things to be naturally aligned (up to 16 bytes). The machines do not require that (anymore), but requiring this in the ABI still is a performance win afaics (and a lot easier for (compiler) implementers -- most issues you describe just disappear ;-) ) Something tells me this won't work for you though? Segher