From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 25EA638515E0 for ; Thu, 10 Jun 2021 22:49:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25EA638515E0 Received: by mail-pf1-x436.google.com with SMTP id y15so2840004pfl.4 for ; Thu, 10 Jun 2021 15:49:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=k3OYyXIF9tfohJJ4+ZvFb9pY8ZpIf5HjL+FN842KeBI=; b=p5Cb6rC4QFYl9JTDSJv0Btp8fqwkVtkGn1pmCdy7HRJ9c3wyy0ymcw3x/oNd3ch/IZ qODexrJwSryeE8+9uGhTkHe/SdCkhMeTGSMRwpPwi2PUgXj25quxEu54A8nlnnhcIs9o 1B/jbQnTWaxKuMterLPoqBCUpZph4t4Pw2sVwSPO89jS52XN9QS1t5Lo2eg4/MKxyMwz HI2toHQstvt+LxGdWT3hILygc9zj87HGa0t+Dk4jCCDMuPxTkcBIx2MiXFODLCbxGykK jr6ZANdet5KnKVGUo5/CoS9GBXGSsY3To5CDqhjTvA6WZ9eFQuTJ1wHgdujcD4sbTour 8MTQ== X-Gm-Message-State: AOAM533qAmxwm6KNIfbCisWovFGa64HPQFpcuSK3b5sQ/ilulpu7JD4L CVu8R1RzoO5puntAGjrPDXebRJevWz/9Dg== X-Google-Smtp-Source: ABdhPJypZ7EnvBmmewSZ5Xy9nSMJjhMcGHgTuMDvEtlEA1Rkw4zBktCNNGFDwneuqV+WunisU1dcCQ== X-Received: by 2002:a63:4b52:: with SMTP id k18mr659517pgl.190.1623365346969; Thu, 10 Jun 2021 15:49:06 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id a13sm3542944pgm.3.2021.06.10.15.49.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Jun 2021 15:49:06 -0700 (PDT) Subject: Re: Aligning stack offsets for spills To: Jakub Jelinek , Jeff Law Cc: Michael Matz , GCC Patches References: <98179c8e-bcec-83ed-5b99-6f54791bd7cd@tachyum.com> <1a10d2db-1867-5dfc-bf08-3b34557c85d4@tachyum.com> <20210608145501.GR7746@tucnak> From: Jeff Law Message-ID: Date: Thu, 10 Jun 2021 16:49:02 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <20210608145501.GR7746@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, 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: Thu, 10 Jun 2021 22:49:09 -0000 On 6/8/2021 8:55 AM, Jakub Jelinek 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 > 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. Hmm, I thought we'd do a dynamic realignment, if that's not the case then we've got another approach to consider. Thanks everyone... jeff