[LLVMdev] Follow-up questions after successful upgrade to LLVM 3.0rc4

Tue Nov 22 09:08:01 PST 2011

We were successful in upgrading our JIT project to LLVM 3.0rc4 last week, after initially struggling with the various usage and IR changes from V2.9.   But we have some follow-up questions:

1)      In spite of building and running our tests cleanly with DEBUG+ASSERTS and RELEASE builds, we consistently see a crash when we use a DEBUG build without ASSERTs.  The crash appears whenever we use the new cmpxchg operator in a tight loop (as it would normally be used).   I don't understand how this can happen.  The only obvious explanations for this are deliberate behavior differences for the build modes, or some kind of handler that recovers from assertion failures.  I've captured the IR from an intermediate dump successfully compiled it with "llc" frequently, using a wide variety of options attempting to match our usage, but it never fails, and always generates reasonable code.  Is anyone interested in having us attempt to pursue this behavior to track down the problem?  Here's a typical crash signature:

#0  0x00007ffff602aa69 in RemoveFromUseList (this=0x696a58)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/VMCore/Value.cpp:493
#1  0x00007ffff54864d5 in ~ValueHandleBase (this=0x689648,
    first=<value optimized out>, last=...)
    at /home/kharris/llvm30/cl-install/include/llvm/Support/ValueHandle.h:74
#2  ~AssertingVH (this=0x689648, first=<value optimized out>, last=...)
    at /home/kharris/llvm30/cl-install/include/llvm/Support/ValueHandle.h:182
#3  _Destroy<llvm::AssertingVH<llvm::Instruction> > (this=0x689648,
    first=<value optimized out>, last=...)
    at /usr/include/c++/4.5/bits/stl_construct.h:89
#4  __destroy<llvm::AssertingVH<llvm::Instruction>*> (this=0x689648,
    first=<value optimized out>, last=...)
    at /usr/include/c++/4.5/bits/stl_construct.h:99
#5  _Destroy<llvm::AssertingVH<llvm::Instruction>*> (this=0x689648,
    first=<value optimized out>, last=...)
    at /usr/include/c++/4.5/bits/stl_construct.h:122
#6  _Destroy<llvm::AssertingVH<llvm::Instruction>*, llvm::AssertingVH<llvm::Instruction> > (this=0x689648, first=<value optimized out>, last=...)
    at /usr/include/c++/4.5/bits/stl_construct.h:148
#7  ~vector (this=0x689648, first=<value optimized out>, last=...)
    at /usr/include/c++/4.5/bits/stl_vector.h:313
#8  ~AliasSet (this=0x689648, first=<value optimized out>, last=...)
    at /home/kharris/llvm30/cl-install/include/llvm/Analysis/AliasSetTracker.h:36
#9  deleteNode (this=0x689648, first=<value optimized out>, last=...)
    at /home/kharris/llvm30/cl-install/include/llvm/ADT/ilist.h:112
#10 erase (this=0x689648, first=<value optimized out>, last=...)
    at /home/kharris/llvm30/cl-install/include/llvm/ADT/ilist.h:463
#11 llvm::iplist<llvm::AliasSet, llvm::ilist_traits<llvm::AliasSet> >::erase (
    this=0x689648, first=<value optimized out>, last=...)
    at /home/kharris/llvm30/cl-install/include/llvm/ADT/ilist.h:528
#12 0x00007ffff5ba926e in clear (this=0x689648)
    at /home/kharris/llvm30/llvm-3.0rc4.src/include/llvm/ADT/ilist.h:532
#13 0x00007ffff5d60748 in clear (this=0x689640)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/Analysis/AliasSetTracker.cpp:208
#14 0x00007ffff5486ef6 in llvm::AliasSetTracker::~AliasSetTracker() ()
   from ../Code_Gen/Debug/libdt_compile.so
#15 0x00007ffff5ba5779 in runOnLoop (this=0x677a20, L=0x684aa0, LPM=...)
---Type <return> to continue, or q <return> to quit---
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/Transforms/Scalar/LICM.cpp:263
#16 0x00007ffff5dd6791 in runOnFunction (this=0x68be80, F=...)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/Analysis/LoopPass.cpp:241
#17 0x00007ffff6008881 in runOnFunction (this=0x691630, F=...)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/VMCore/PassManager.cpp:1512
#18 0x00007ffff5d43a11 in RunPassOnSCC (this=0x695e10, P=0x691630, CurSCC=..., CG=...,
    CallGraphUpToDate=@0x7fff73a6338e, DevirtualizedCall=@0x7fff73a63453)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/Analysis/IPA/CallGraphSCCPass.cpp:145
#19 0x00007ffff5d43392 in RunAllPassesOnSCC (this=0x695e10, CurSCC=..., CG=...,
    DevirtualizedCall=@0x7fff73a63453)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/Analysis/IPA/CallGraphSCCPass.cpp:399
#20 0x00007ffff5d42d94 in runOnModule (this=0x695e10, M=...)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/Analysis/IPA/CallGraphSCCPass.cpp:455
#21 0x00007ffff6008f22 in runOnModule (this=0x67a650, M=...)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/VMCore/PassManager.cpp:1588
#22 0x00007ffff600961b in run (this=0x67a000, M=...)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/VMCore/PassManager.cpp:1672
#23 0x00007ffff6009acd in run (this=0x675da0, M=...)
    at /home/kharris/llvm30/llvm-3.0rc4.src/lib/VMCore/PassManager.cpp:1716
#24 0x00007ffff547c735 in dt_llvm_compile_function () at Debug/../dt_llvm.cpp:7518
#25 0x00007ffff54540ff in generateFunc () at Debug/../dt_interface.cpp:1014
#26 compiler_thread () at Debug/../dt_interface.cpp:791
#27 0x00007ffff79c3a4f in start_thread () from /lib64/libpthread.so.0
#28 0x00007ffff6fb782d in clone () from /lib64/libc.so.6
#29 0x0000000000000000 in ?? ()

2)      I had no problem running the V3.0 regression tests according to the instructions.  However, the instructions in the Testing Infrastructure Guide for running the Test Suite presume the existence and use of llvm-gcc, http://llvm.org/docs/TestingGuide.html, both on-line and in the rc4 kits.  Now that llvm-gcc is gone for V3.0, it isn't completely obvious how to run the test-suite using clang rather than llvm-gcc.  I've made a couple stabs at it without success.  If there is new documentation that I've missed, please be kind when you point out where I should have looked.  :-}
3)      We see a modest performance improvement from the use of V3.0rc4, over V2.9, but our largest test appears to run out of memory during the Greedy Register allocator when we enable our extensive Type Based Alias Analysis tags in the IR, and run in DEBUG+ASSERTs mode (but not in RELEASE mode).  I'm somewhat at a loss in how to properly report this problem, with basic blocks numbering in the thousands.  If anyone is interested in tracking this down, please provide some suggestions about how to capture the IR and environmental info to file a meaningful bug report.

        Thanks in advance for any info on these topics!

        -Kevin Harris, Unisys

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