When I try to add LICM to a FunctionPassManager, I get a crash. This happens
using CVS HEAD versions of LLVM from 2-July (on X86) and 13-July (on SparcV9).
I will attach my test program along with a GDB backtrace shortly.

Created an attachment (id=161) [details]
Test program

This is the test program which I used to trigger the bug.
It simply runs LICM on a function that the user names on the command line,
after reading in a module.

This is the backtrace from the test program when it crashes.


37 zion> gdb --args ../Debug/foo -bc=RealMM.llvm.bc -func=rInitmatrix
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run
Starting program: /home/vadve/gaeke/llvm/tools/Debug/foo -bc=RealMM.llvm.bc -func=rInitmatrix

Program received signal SIGSEGV, Segmentation fault.
0x0822354b in llvm::Type::getForwardedType() const (this=0x0) at Type.h:232
232         if (!ForwardType) return 0;
(gdb) where
#0  0x0822354b in llvm::Type::getForwardedType() const (this=0x0) at Type.h:232
#1  0x08222855 in llvm::PATypeHolder::get() const (this=0x841cae8) at Type.h:359
#2  0x082226c9 in llvm::PATypeHolder::operator llvm::Type const*() const (
    this=0x841cae8) at AbstractTypeUser.h:148
#3  0x08220322 in llvm::Value::getType() const (this=0x841cae0) at Value.h:67
#4  0x0834f247 in getUnderlyingObject (V=0x841cae0) at BasicAliasAnalysis.cpp:133
#5  0x0834f60f in (anonymous namespace)::BasicAliasAnalysis::pointsToConstantMemory(llvm::Value 
const*) (this=0x8421310, P=0x841cae0) at BasicAliasAnalysis.cpp:182
#6  0x083177b7 in llvm::PassManagerT<llvm::Function>::add(llvm::FunctionPass*) (
    this=0x841cae0, P=0x8421310) at PassManagerT.h:465
#7  0x0831778a in llvm::PassManagerT<llvm::Function>::add(llvm::FunctionPass*) (
    this=0x841cae0, P=0x841cb38) at PassManagerT.h:458
#8  0x082c8242 in llvm::FunctionPassManager::add(llvm::FunctionPass*) (this=0xbfffe950, 
    P=0x841cb38) at Pass.cpp:91
#9  0x0821b544 in main (argc=3, argv=0xbfffe9e4) at foo.cpp:39
(gdb)

From LICM.cpp:

    /// This transformation requires natural loop information & requires that
    /// loop preheaders be inserted into the CFG...
    ///
    virtual void getAnalysisUsage(AnalysisUsage &AU) const {
      AU.setPreservesCFG();
      AU.addRequiredID(LoopSimplifyID);
      AU.addRequired<LoopInfo>();
      AU.addRequired<DominatorTree>();
      AU.addRequired<DominanceFrontier>();  // For scalar promotion (mem2reg)
      AU.addRequired<AliasAnalysis>();
    }

Is it simply the case that LICM, being a FunctionPass, can't require AliasAnalysis?

The problem with this is that LICM depends on alias analysis, and the default
one is basicaa.  Basicaa is an immutable pass, which does not fit into a pass
manager.

As a workaround that won't work, you shoulda been able to add a custom
AliasAnalysis that derives from FunctionPass, that is a noop.  However, loop
simplify will invalidate this pass, so it won't be used anyway.  This is clearly
a problem, but unrelated to this one.

The real solution to this problem is fixing Bug 36 unfortunately.

-Chris

I'm not sure that you can't add immutable passes to FunctionPassManagers. In
particular, I added the special add() method at PassManagerT.h:468-488 explicitly
so that FunctionPassManager could accept immutable passes. Does that not work?

Also, FYI, I get the same crash if I use 
  PM.add(createLoadValueNumberingPass());
  PM.add(createGCSEPass());
instead of
  PM.add(createLICMPass());
contrary to what you mentioned on IRC (unless my memory fails me...)

My original theory was that this was broken because function passes can't require
module passes...

> I added the special add() method at PassManagerT.h:468-488 explicitly
> so that FunctionPassManager could accept immutable passes. Does that not work?

You tell me :)

> Also, FYI, I get the same crash if I use LoadVN/GCSE

Yes, this is because it's pulling in basicaa as the default impl of alias
analysis for load-vn.  With this combination however (not with licm) you could
write a custom FunctionPass AliasAnalysis that does not chain.  Because it would
be a function pass, it would not cause this issue.

For LICM, you can't do this, because it depends on loopsimplify, which
invalidates alias analyses.

-Chris

GCSE isn't the problem.  The problem is -basicaa

-Chris

The test program runs to completion with this patch to the PassManager:

http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040719/016391.html