llvm dev - Jul 2013 - [LLVMdev] SIMD instructions and memory alignment on X86

Hello all,

I'm currently in the process of debugging a crash occurring in our 
program. In LLVM 3.2 and 3.3 it appears that JIT generated code is 
attempting to perform access unaligned memory with a SSE2 instruction. 
However this only happens under certain conditions that seem (but may 
not be) related to the stacks state on calling the function.

Our program acts as a front-end, using the LLVM C++ API to generate a 
JIT generated function. This function is primarily mathematical, so we 
use the Vector types to take advantage of SIMD instructions (as well as 
a few SSE2 intrinsics).

This worked in LLVM 2.8 but started failing in 3.2 and has continued to 
fail in 3.3. It fails with no optimizations applied to the LLVM 
Function/Module. It crashes with what is reported as a memory access 
error (accessing 0xffffffff), however it's suggested that this is how 
the SSE fault raising mechanism appears.

The generated instruction varies, but it seems to often be similar to (I 
don't have it in front of me, sorry):
movapd xmm0, xmm[ecx+0x???????]
Where the xmm register changes, and the second parameter is a memory access.
ECX is always set to 0x7ffffff - however I don't know if this is part of 
the SSE error reporting process or is part of the situation causing the 
error.

I haven't worked out exactly what code path etc is causing this crash. 
I'm hoping that someone can tell me if there were any changed 
requirements for working with SIMD in LLVM 3.2 (or earlier, we haven't 
tried 3.0 or 3.1). I currently suspect the use of GlobalVariable (we 
first discovered the crash when using a feature that uses them), however 
I have attempted using setAlignment on the GlobalVariables without any 
change.

--
Peter N

As someone off list just told me, perhaps my new bug is the same issue:

  http://llvm.org/bugs/show_bug.cgi?id=16640

Do you happen to be using FastISel?

Solomon

On Jul 16, 2013, at 6:39 PM, Peter Newman <peter at uformia.com> wrote:
> Hello all,
> 
> I'm currently in the process of debugging a crash occurring in our
program. In LLVM 3.2 and 3.3 it appears that JIT generated code is attempting to
perform access unaligned memory with a SSE2 instruction. However this only
happens under certain conditions that seem (but may not be) related to the
stacks state on calling the function.
> 
> Our program acts as a front-end, using the LLVM C++ API to generate a JIT
generated function. This function is primarily mathematical, so we use the
Vector types to take advantage of SIMD instructions (as well as a few SSE2
intrinsics).
> 
> This worked in LLVM 2.8 but started failing in 3.2 and has continued to
fail in 3.3. It fails with no optimizations applied to the LLVM Function/Module.
It crashes with what is reported as a memory access error (accessing
0xffffffff), however it's suggested that this is how the SSE fault raising
mechanism appears.
> 
> The generated instruction varies, but it seems to often be similar to (I
don't have it in front of me, sorry):
> movapd xmm0, xmm[ecx+0x???????]
> Where the xmm register changes, and the second parameter is a memory
access.
> ECX is always set to 0x7ffffff - however I don't know if this is part
of the SSE error reporting process or is part of the situation causing the
error.
> 
> I haven't worked out exactly what code path etc is causing this crash.
I'm hoping that someone can tell me if there were any changed requirements
for working with SIMD in LLVM 3.2 (or earlier, we haven't tried 3.0 or 3.1).
I currently suspect the use of GlobalVariable (we first discovered the crash
when using a feature that uses them), however I have attempted using
setAlignment on the GlobalVariables without any change.
> 
> --
> Peter N
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Unfortunately, this doesn't appear to be the bug I'm hitting. I applied 
the fix to my source and it didn't make a difference.

Also further testing found me getting the same behavior with other SIMD 
instructions. The common factor is in each case, ECX is set to 
0x7fffffff, and it's an operation using xmm ptr ecx+offset .

Additionally, turning the optimization level passed to createJIT down 
appears to avoid it, so I'm now leaning towards a bug in one of the 
optimization passes.

I'm going to dig through the passes controlled by that parameter and see 
if I can narrow down which optimization is causing it.

Peter N

On 17/07/2013 1:58 PM, Solomon Boulos wrote:
> As someone off list just told me, perhaps my new bug is the same issue:
>
>    http://llvm.org/bugs/show_bug.cgi?id=16640
>
> Do you happen to be using FastISel?
>
> Solomon
>
> On Jul 16, 2013, at 6:39 PM, Peter Newman <peter at uformia.com>
wrote:
>
>> Hello all,
>>
>> I'm currently in the process of debugging a crash occurring in our
program. In LLVM 3.2 and 3.3 it appears that JIT generated code is attempting to
perform access unaligned memory with a SSE2 instruction. However this only
happens under certain conditions that seem (but may not be) related to the
stacks state on calling the function.
>>
>> Our program acts as a front-end, using the LLVM C++ API to generate a
JIT generated function. This function is primarily mathematical, so we use the
Vector types to take advantage of SIMD instructions (as well as a few SSE2
intrinsics).
>>
>> This worked in LLVM 2.8 but started failing in 3.2 and has continued to
fail in 3.3. It fails with no optimizations applied to the LLVM Function/Module.
It crashes with what is reported as a memory access error (accessing
0xffffffff), however it's suggested that this is how the SSE fault raising
mechanism appears.
>>
>> The generated instruction varies, but it seems to often be similar to
(I don't have it in front of me, sorry):
>> movapd xmm0, xmm[ecx+0x???????]
>> Where the xmm register changes, and the second parameter is a memory
access.
>> ECX is always set to 0x7ffffff - however I don't know if this is
part of the SSE error reporting process or is part of the situation causing the
error.
>>
>> I haven't worked out exactly what code path etc is causing this
crash. I'm hoping that someone can tell me if there were any changed
requirements for working with SIMD in LLVM 3.2 (or earlier, we haven't tried
3.0 or 3.1). I currently suspect the use of GlobalVariable (we first discovered
the crash when using a feature that uses them), however I have attempted using
setAlignment on the GlobalVariables without any change.
>>
>> --
>> Peter N
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev