Follow-up questions after successful upgrade to LLVM 3.0rc4

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=, last=…)
at /home/kharris/llvm30/cl-install/include/llvm/Support/ValueHandle.h:74
#2 ~AssertingVH (this=0x689648, first=, last=…)
at /home/kharris/llvm30/cl-install/include/llvm/Support/ValueHandle.h:182
#3 _Destroy<llvm::AssertingVHllvm::Instruction > (this=0x689648,
first=, last=…)
at /usr/include/c++/4.5/bits/stl_construct.h:89
#4 __destroy<llvm::AssertingVHllvm::Instruction> (this=0x689648,
first=, last=…)
at /usr/include/c++/4.5/bits/stl_construct.h:99
#5 _Destroy<llvm::AssertingVHllvm::Instruction
> (this=0x689648,
first=, last=…)
at /usr/include/c++/4.5/bits/stl_construct.h:122
#6 _Destroy<llvm::AssertingVHllvm::Instruction*, llvm::AssertingVHllvm::Instruction > (this=0x689648, first=, last=…)
at /usr/include/c++/4.5/bits/stl_construct.h:148
#7 ~vector (this=0x689648, first=, last=…)
at /usr/include/c++/4.5/bits/stl_vector.h:313
#8 ~AliasSet (this=0x689648, first=, last=…)
at /home/kharris/llvm30/cl-install/include/llvm/Analysis/AliasSetTracker.h:36
#9 deleteNode (this=0x689648, first=, last=…)
at /home/kharris/llvm30/cl-install/include/llvm/ADT/ilist.h:112
#10 erase (this=0x689648, first=, last=…)
at /home/kharris/llvm30/cl-install/include/llvm/ADT/ilist.h:463
#11 llvm::iplist<llvm::AliasSet, llvm::ilist_traitsllvm::AliasSet >::erase (
this=0x689648, first=, 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 to continue, or q 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 ?? ()

  1. 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. :-}
  2. 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

Hi Kevin,

   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:

try running under valgrind.

   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
      <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. :-}

Pass LLVMCC_OPTION=clang ENABLE_BUILT_CLANG=1 to make when running the
testsuite.

   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.

Is there really a problem getting hold of the IR? I don't know what front-end
you are using but most of them have a way of outputting IR. If running llc on
the IR runs out of memory then I guess you can gzip it up and attach it to a bug
report.

Ciao, Duncan.

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. :-}

  LLVM / CLANG Test Infrastructure Question
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041954.html

HTH,
chenwj

It would be great to have some of this info was moved to the docs.

Ciao, Duncan.

陳韋任 <chenwj@iis.sinica.edu.tw> writes:

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. :-}

  LLVM / CLANG Test Infrastructure Question
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041954.html

This has been hit by several people (at least) now. The documentation
needs an update.

                             -Dave

It's on my list.

-eric

Eric Christopher <echristo@apple.com> writes: