From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 2C6D0395B803 for ; Tue, 8 Jun 2021 14:55:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C6D0395B803 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-446-o2UmaWi9OPugfVgcgWTv_g-1; Tue, 08 Jun 2021 10:55:06 -0400 X-MC-Unique: o2UmaWi9OPugfVgcgWTv_g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AB0C1800D62; Tue, 8 Jun 2021 14:55:05 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-147.ams2.redhat.com [10.36.112.147]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 424CF5D9DE; Tue, 8 Jun 2021 14:55:05 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 158Et3Qt4127490 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 8 Jun 2021 16:55:03 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 158Et24u4127489; Tue, 8 Jun 2021 16:55:02 +0200 Date: Tue, 8 Jun 2021 16:55:01 +0200 From: Jakub Jelinek To: Jeff Law Cc: Michael Matz , GCC Patches Subject: Re: Aligning stack offsets for spills Message-ID: <20210608145501.GR7746@tucnak> Reply-To: Jakub Jelinek References: <98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com> <1a10d2db-1867-5dfc-bf08-3b34557c85d4@tachyum.com> MIME-Version: 1.0 In-Reply-To: <1a10d2db-1867-5dfc-bf08-3b34557c85d4@tachyum.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Tue, 08 Jun 2021 14:55:09 -0000 On Tue, Jun 08, 2021 at 08:47:26AM -0600, Jeff Law wrote: > > Why is the machinery involving STACK_SLOT_ALIGNMENT and > > spill_slot_alignment() (for spilling) or get_stack_local_alignment() (for > > backing stack slots) not working for you? If everything is setup > > correctly the input alignment to try_fit_stack_local ought to be correct > > already. > We don't need the MEM as a whole aligned, just the offset in the address > calculation due to how we encode those instructions.  If I've read that code > correctly, it would arrange for a dynamic realignment of the stack  so that > it could then align the slot. None of that is necessary for us and we'd like > to avoid forcing the dynamic stack realignment.  Or did I misread the code? I think dynamic stack realignment is done only on x86, no other backend has that support, on all the other arches larger alignments are done in expand_stack_vars by effectively performing __builtin_alloca_with_align for the block containing all such variables. So I'd the the functions Michael mentioned shouldn't be doing dynamic stack realignment, though perhaps by pretending the vars have higher alignment might be recorded in MEM_ALIGN and perhaps might result in wrong-code if something will try to e.g. test if least significant bits of certain MEM address are 0. Jakub