On Thu, Aug 2, 2012 at 6:42 PM, Max Brister<address@hidden> wrote:
On Thu, Aug 2, 2012 at 8:36 AM, Michael Goffioul
<address@hidden> wrote:
On Thu, Aug 2, 2012 at 1:57 PM, Max Brister<address@hidden> wrote:
[snip]
The output with OCTAVE_JIT_DEBUG looks correct to me.
I have attached the patch for llvm 3.1.
I applied it, but it didn't change anything (the generated assembly
looks
exactly the same). If I'm reading this [1] correctly (XF86SubTarget
constructor), the stack alignment was already set to 4 anyway. And in
[2],
in X86_32TargetMachine constructor, the native stack alignment is also
specified on 4 bytes (trailing "-S32" at line 45).
Michael.
[1]
https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/X86Subtarget.cpp
[2]
https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/X86TargetMachine.cpp
Actually, that makes sense. In order to use the sse instruction, we
really want the stack to 16 byte aligned I think. Can you try changing
the stack alignment to 16 bytes instead of 4?
No luck. I've modified your patch to read:
opts.StackAlignmentOverride = 16
For your information, I've attached the generated assembly for the 4-bytes
and 16-bytes case. The code still crashes, but at an earlier location. Now
it crashes at the MOVAPD call (address 02D300BC). If you compare with the
4-bytes case, the latter uses MOVUPD instead, so it doesn't crash. Also if
you compare the 2 files, you see that in the 16-bytes case, all stack
offsets are multiple of 16 bytes, but I don't see any code to realign the
stack on a 16-bytes boundary.
The bottom line is: within the generated code, the stack is kept aligned
on 16-bytes, but as there's no forced realignment, it entirely depends on
the stack alignment on function entry.