[LLVMdev] ModulePass Strangeness and OnTheFly Pass Management

[Jason Kim]

Hi everyone

In a recent rev of llvm [203866], I tried adding a ModulePass as part of
IPO/ which uses the "on the fly" system to have access to Scalar Evolution
and other related analyeses, but quickly ran into a problem.

Inside my ModulePass's runOnModule(), I am able to successfully use
getAnalysisIfAvailable<DataLayoutPass>() to get a pointer to the
DataLayout.

However, within ScalarEvolution's runOnFunction(), the comparable call
to get at the DataLayout always returns NULL.
This normally isn't a problem unless you are in a 32bit land - which
causes SCEV to do lots of fun things like unnecessary conversion to 64bit
types etc...

This happens regardless of whether or not DataLayout pass is declared in
the ModulePass's getAnalysisUsage().

I've managed to get around this issue using an absolutely horrendous hack
in MPPassManager::addLowerLevelRequiredPass so that a new DataLayoutPass
instance can be correctly added.

Unfortunately, this exposes an even bigger problem exposed by
--debug-pass=Details:

Pass Arguments:  -targetlibinfo -datalayout -notti -basictti -x86tti -foo
-verify
Target Library Information
Data Layout
No target information
Target independent code generator's TTI
X86 Target Transform Info
  ModulePass Manager
    Foo
      Unnamed pass: implement Pass::getPassName()
    FunctionPass Manager
      Module Verifier
Pass Arguments:  -no-aa -targetlibinfo -domtree -loops -scalar-evolution -da
No Alias Analysis (always returns 'may' alias)
Target Library Information
  FunctionPass Manager
    Dominator Tree Construction
    Natural Loop Information
    Scalar Evolution Analysis
    Dependence Analysis
0x.   Executing Pass 'Foo' on Module 'foo.ll'...
0x.     Required Analyses: Natural Loop Information, No target
information, Dominator Tree Construction, Dependence Analysis, Scalar
Evolution Analysis
0x.   Executing Pass 'Dominator Tree Construction' on Function 'foo'...
0x.   Executing Pass 'Natural Loop Information' on Function 'foo'...
0x.     Required Analyses: Dominator Tree Construction
0x.   Executing Pass 'Scalar Evolution Analysis' on Function 'foo'...
0x.     Required Analyses: Natural Loop Information, Dominator Tree
Construction, Target Library Information
0x.   Executing Pass 'Dependence Analysis' on Function 'foo'...
0x.     Required Analyses: No Alias Analysis (always returns 'may' alias),
Scalar Evolution Analysis, Natural Loop Information

So now, dependence analysis always defaults to the NoAliasAnalysis,
regardless of whether AliasAnalysis is declared as a direct dependency.
Since AA is not a "pass" per se, I am somewhat confused as to how to "hack
around" this problem.

With some amount of software archaeology, it seems that the OnTheFly pass
management for ModulePasses is likely forgetting the required pass
details, and it seems to have been never really tested.

Can anyone suggest a way forward?
Thanks!

-jason
p.s.
There are a few minor patches for problems/crashes encountered while doing
this experiment. I'll post them soon to llvm-commits for review.

Thanks again