Richard Biener wrote: > On Thu, Oct 5, 2017 at 1:07 AM, Jeff Law <l...@redhat.com> wrote: > > On 10/04/2017 08:53 AM, Eric Botcazou wrote: >>>> This seems like a SPARC target problem to me -- essentially it's >>>> claiming a higher STACK_BOUNDARY than it really has. >>> >>> No, it is not, I can guarantee you that the stack pointer is always aligned >>> to >>> 64-bit boundaries on SPARC, otherwise all hell would break loose... >> Then something is inconsistent somehwere. Either the stack is aligned >> prior to that code or it is not. If it is aligned, then Wilco's patch >> ought to keep it aligned. If is not properly aligned, then well, that's >> the problem ISTM. >> >> Am I missing something here? > > What I got from the discussion and the PR is that the stack hardregister > is properly aligned but what GCC maps to it (virtual or frame or whatever) > might not be at all points. > > allocate_dynamic_stack_space uses virtual_stack_dynamic_rtx and I'm not > sure STACK_BOUNDARY applies to it?
Yes STACK_BOUNDARY applies to virtual_stack_dynamic_rtx and all other virtual frame registers. It appears it's main purpose is to enable alignment optimizations since PREFERRED_STACK_BOUNDARY is used to align local and outgoing argument area etc. So if you don't want the alignment optimizations it is feasible to set STACK_BOUNDARY to a lower value without changing the stack layout. There is also STACK_DYNAMIC_OFFSET which computes the total offset from the stack. It's not obvious whether the default version should align (since outgoing arguments are already aligned there is no easy way to record the extra padding), but we could assert if the offset isn't aligned. Wilco
