On 04/14/2015 10:30 AM, Steve Ellcey wrote:
On Mon, 2015-04-13 at 23:18 -0600, Jeff Law wrote:
But I don't see how using alloca ensures that you're going to have an
aligned spill slot. It can get you an aligned stack pointer, but that
doesn't ensure alignment of any particular spill slot IIRC.
It doesn't. I found a big hole in my idea because as soon as you do an alloca
then frame_pointer_needed is set to true and spills are done relative to
the frame pointer, not the stack pointer. Thus having an aligned stack
pointer at that point doesn't help at all with the alignment of spills.
Right. I almost mentioned something about the frame pointer here...
But yes, once you do alloca, spills are going to be frame relative.
I don't recall if we can have a different alignment requirements for the
frame and stack. Even if we can get an aligned frame, that's still not
a guarantee of an aligned spill slot.
Yes, I am trying to look at how the x86 does dynamic stack alignment but
it is difficult to untangle the generic concepts from the parts tied
specifically to the x86 calling convention. No other platform appears
to do dynamic stack alignment.
I'm not aware of any other target doing dynamic stack realignment. x86
has a long history of alignment issues (*), so folks have been thinking
about how to do it there for a long time.
I'm a bit surprised this hasn't come up on other architectures given the
proliferation of wider and wider vectors. If you can see a path to
generalization of what the x86 is doing so that other targets can use
it, it'd definitely be a win.
Jeff
(*) I'm referring to the fact that doubles are natively 32 bit aligned,
but you could get far better performance if you 64 bit align them.
That's where preferred stack boundary came from, which was a preference,
not a requirement. Dynamic stack realignment and such came later.