<
address@hidden> wrote:
> On Thu, Aug 2, 2012 at 8:54 PM, Michael Goffioul
> <
address@hidden> wrote:
>>
>> 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.
>
>
> Any update, ideas or suggestions?
>
> Michael.
>