On Tue, Jun 8, 2021 at 7:56 AM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> 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.
