[LLVMdev] SIMD instructions and memory alignment on X86

[Craig Topper]

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> 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<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<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>
>>
> ______________________________**_________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<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/20130717/6dc2582f/attachment.html>