<div dir="ltr">What is "frep.x86.sse2.sqrt.pd". I'm only familiar with things prefixed with "llvm.x86".</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 18, 2013 at 10:12 PM, Peter Newman <span dir="ltr"><<a href="mailto:peter@uformia.com" target="_blank">peter@uformia.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>After stepping through the produced
      assembly, I believe I have a culprit.<br>
      <br>
      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.<br>
      <br>
      Peter N<div><div class="h5"><br>
      <br>
      On 19/07/2013 2:09 PM, Peter Newman wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      
      <div>I've attached the module->dump()
        that our code is producing. Unfortunately this is the smallest
        test case I have available.<br>
        <br>
        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.<br>
        <br>
        The function in module-dump.ll (called crashfunc in this file)
        is called with<br>
        -        func_params    0x0018f3b0    double [3]<br>
                [0x0]    -11.339976634695301    double<br>
                [0x1]    -9.7504239056205506    double<br>
                [0x2]    -5.2900856817382804    double<br>
        at the time of the exception.<br>
        <br>
        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 ) ).<br>
        <br>
        Hopefully this is reproducible for you.<br>
        <br>
        --<br>
        PeterN<br>
        <br>
        On 18/07/2013 4:37 PM, Craig Topper wrote:<br>
      </div>
      <blockquote type="cite">
        <div dir="ltr">Are you able to send any IR for others to
          reproduce this issue?</div>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On Wed, Jul 17, 2013 at 11:23 PM,
            Peter Newman <span dir="ltr"><<a href="mailto:peter@uformia.com" target="_blank">peter@uformia.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
              <br>
              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 .<br>
              <br>
              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.<br>
              <br>
              I'm going to dig through the passes controlled by that
              parameter and see if I can narrow down which optimization
              is causing it.<br>
              <br>
              Peter N
              <div>
                <div><br>
                  <br>
                  On 17/07/2013 1:58 PM, Solomon Boulos wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    As someone off list just told me, perhaps my new bug
                    is the same issue:<br>
                    <br>
                       <a href="http://llvm.org/bugs/show_bug.cgi?id=16640" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=16640</a><br>
                    <br>
                    Do you happen to be using FastISel?<br>
                    <br>
                    Solomon<br>
                    <br>
                    On Jul 16, 2013, at 6:39 PM, Peter Newman <<a href="mailto:peter@uformia.com" target="_blank">peter@uformia.com</a>>

                    wrote:<br>
                    <br>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      Hello all,<br>
                      <br>
                      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.<br>
                      <br>
                      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).<br>
                      <br>
                      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.<br>
                      <br>
                      The generated instruction varies, but it seems to
                      often be similar to (I don't have it in front of
                      me, sorry):<br>
                      movapd xmm0, xmm[ecx+0x???????]<br>
                      Where the xmm register changes, and the second
                      parameter is a memory access.<br>
                      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.<br>
                      <br>
                      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.<br>
                      <br>
                      --<br>
                      Peter N<br>
                      _______________________________________________<br>
                      LLVM Developers mailing list<br>
                      <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>        
                      <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
                      <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
                    </blockquote>
                  </blockquote>
                  <br>
                  _______________________________________________<br>
                  LLVM Developers mailing list<br>
                  <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>
                          <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
                  <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          ~Craig </div>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br>~Craig
</div>