On Thu, Oct 26, 2017 at 4:55 PM, Jeff Law <l...@redhat.com> wrote: > On 10/17/2017 06:04 AM, Wilco Dijkstra wrote: >> Wilco Dijkstra wrote: >>> >>> 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. >> >> Also there is something odd in the sparc backend: >> >> /* Given the stack bias, the stack pointer isn't actually aligned. */ >> #define INIT_EXPANDERS \ >> do { \ >> if (crtl->emit.regno_pointer_align && SPARC_STACK_BIAS) \ >> { \ >> REGNO_POINTER_ALIGN (STACK_POINTER_REGNUM) = BITS_PER_UNIT; \ >> REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = BITS_PER_UNIT; \ >> } \ >> } while (0) >> >> That lowers the alignment for the stack and frame pointer. So assuming that >> works >> and blocks alignment optimizations, why isn't this done for the dynamic >> offset as well? > No clue, but ISTM that it should. Eric, can you try that and see if it > addresses these problems? I'd really like to get this wrapped up, but I > don't have access to any sparc systems to test it myself.
Or maybe adjust all non-hardreg stack pointers by the bias so they _are_ aligned. And of course make sure we always use the aligned pointers when allocating. Weird ABI ... Richard. > Jeff