[LLVMdev] SIMD instructions and memory alignment on X86

Thu Jul 18 22:12:58 PDT 2013

After stepping through the produced assembly, I believe I have a culprit.

One of the calls to @frep.x86.sse2.sqrt.pd is modifying the value of ECX 
- while the produced code is expecting it to still contain its previous 
value.

Peter N

On 19/07/2013 2:09 PM, Peter Newman wrote:
> I've attached the module->dump() that our code is producing. 
> Unfortunately this is the smallest test case I have available.
>
> This is before any optimization passes are applied. There are two 
> separate modules in existence at the time, and there are no guarantees 
> about the order the surrounding code calls those functions, so there 
> may be some interaction between them? There shouldn't be, they don't 
> refer to any common memory etc. There is no multi-threading occurring.
>
> The function in module-dump.ll (called crashfunc in this file) is 
> called with
> -        func_params    0x0018f3b0    double [3]
>         [0x0]    -11.339976634695301    double
>         [0x1]    -9.7504239056205506    double
>         [0x2]    -5.2900856817382804    double
> at the time of the exception.
>
> This is compiled on a "i686-pc-win32" triple. All of the non-intrinsic 
> functions referred to in these modules are the standard equivalents 
> from the MSVC library (e.g. @asin is the standard C lib    double 
> asin( double ) ).
>
> Hopefully this is reproducible for you.
>
> --
> PeterN
>
> On 18/07/2013 4:37 PM, Craig Topper wrote:
>> Are you able to send any IR for others to reproduce this issue?
>>
>>
>> On Wed, Jul 17, 2013 at 11:23 PM, Peter Newman <peter at uformia.com 
>> <mailto:peter at uformia.com>> wrote:
>>
>>     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
>>         <mailto: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 <mailto:LLVMdev at cs.uiuc.edu>
>>             http://llvm.cs.uiuc.edu
>>             http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>>     http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>> -- 
>> ~Craig
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130719/9de718fe/attachment.html>