[LLVMdev] SIMD instructions and memory alignment on X86
craig.topper at gmail.com
Thu Jul 18 22:25:59 PDT 2013
What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things prefixed
On Thu, Jul 18, 2013 at 10:12 PM, Peter Newman <peter at uformia.com> wrote:
> 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
> - func_params 0x0018f3b0 double 
> [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.
> 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> 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:
>>> Do you happen to be using FastISel?
>>> 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
>>>> 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
>>>> 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
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev