[LLVMdev] SIMD instructions and memory alignment on X86
Peter Newman
peter at uformia.com
Thu Jul 18 22:45:15 PDT 2013
In the disassembly, I'm seeing three cases of
call 76719BA1
I am assuming this is the sqrt function as this is the only function
called in the LLVM IR.
The code at 76719BA1 is:
76719BA1 push ebp
76719BA2 mov ebp,esp
76719BA4 sub esp,20h
76719BA7 and esp,0FFFFFFF0h
76719BAA fld st(0)
76719BAC fst dword ptr [esp+18h]
76719BB0 fistp qword ptr [esp+10h]
76719BB4 fild qword ptr [esp+10h]
76719BB8 mov edx,dword ptr [esp+18h]
76719BBC mov eax,dword ptr [esp+10h]
76719BC0 test eax,eax
76719BC2 je 76719DCF
76719BC8 fsubp st(1),st
76719BCA test edx,edx
76719BCC js 7671F9DB
76719BD2 fstp dword ptr [esp]
76719BD5 mov ecx,dword ptr [esp]
76719BD8 add ecx,7FFFFFFFh
76719BDE sbb eax,0
76719BE1 mov edx,dword ptr [esp+14h]
76719BE5 sbb edx,0
76719BE8 leave
76719BE9 ret
As you can see at 76719BD5, it modifies ECX .
I don't know that this is the sqrtpd function (for example, I'm not
seeing any SSE instructions here?) but whatever it is, it's being called
from the IR I attached earlier, and is modifying ECX under some
circumstances.
On 19/07/2013 3:29 PM, Craig Topper wrote:
> That should map directly to sqrtpd which can't modify ecx.
>
>
> On Thu, Jul 18, 2013 at 10:27 PM, Peter Newman <peter at uformia.com
> <mailto:peter at uformia.com>> wrote:
>
> Sorry, that should have been llvm.x86.sse2.sqrt.pd
>
>
> On 19/07/2013 3:25 PM, Craig Topper wrote:
>> What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things
>> prefixed with "llvm.x86".
>>
>>
>> On Thu, Jul 18, 2013 at 10:12 PM, Peter Newman <peter at uformia.com
>> <mailto: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 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
>>>
>>
>>
>>
>>
>> --
>> ~Craig
>
>
>
>
> --
> ~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130719/181387d3/attachment.html>
More information about the llvm-dev
mailing list