From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id E0C7E383540C for ; Tue, 8 Jun 2021 15:07:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E0C7E383540C Received: by mail-oi1-x235.google.com with SMTP id t40so8812871oiw.8 for ; Tue, 08 Jun 2021 08:07:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0VSJ+yCGrr47KXaFLWOKBcOhRWn1AVbLrJTIFdNbNvw=; b=WY2L2iSez3xkrVVZmtoaR90TofA5vN8jkzQRKNwLoao9MJR0yD08CWj0k7wN7r0I4b x0VBtmRzjmNHxDNZfEyKYaTjPiK4CKxLaLDSxmzgmLI3lDfCB7aIpG2/9l3/+bytxXxd Fod2kyC+M0bj2oaO1fX9wal1AN0HjfJpIvDji/WP+QJoeUUF+muOzP6hA60KFniGyVlG CNJHaA54QL3EqDrxQRWkS3DJNDzMt7QxZ9n9AYl+mp9pGeyC+dmXtWo/KGTBKxJ9voMp 4UnFUxdY9hUwgJrvYaJIILUNp4fXU4vlYFIFwDQ+kcCQTp4SdhbxpXZRIHAw867IxHTb Tu+w== X-Gm-Message-State: AOAM530uE2mzhgV/9cRu5SZUVTqpHZ8w+RwYg7yy8JeQplwZm5TrnfnC aoOyjLhTySAV3osxBXsufgI83iqaLKZyI+qApE8= X-Google-Smtp-Source: ABdhPJz3TZ/OU/hrny1yELNyM9niOF7eQCMJQzqQN6gkEWcNqlewWivyvSE9NxLt2dIVlDi/GM+B6fzEEcPlYjY0b+s= X-Received: by 2002:aca:5bd4:: with SMTP id p203mr3148401oib.116.1623164839273; Tue, 08 Jun 2021 08:07:19 -0700 (PDT) MIME-Version: 1.0 References: <98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com> <1a10d2db-1867-5dfc-bf08-3b34557c85d4@tachyum.com> <20210608145501.GR7746@tucnak> In-Reply-To: <20210608145501.GR7746@tucnak> From: "H.J. Lu" Date: Tue, 8 Jun 2021 08:06:43 -0700 Message-ID: Subject: Re: Aligning stack offsets for spills To: Jakub Jelinek Cc: Jeff Law , Michael Matz , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3028.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 15:07:26 -0000 On Tue, Jun 8, 2021 at 7:56 AM Jakub Jelinek via Gcc-patches wrote: > > 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 I believe that all pieces of infrastructure to realign the stack are in place. You just need to properly align the stack in the backend. > 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 > -- H.J.