In a recent rev of llvm , 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
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
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
Pass Arguments: -targetlibinfo -datalayout -notti -basictti -x86tti -foo
Target Library Information
No target information
Target independent code generator's TTI
X86 Target Transform Info
Unnamed pass: implement Pass::getPassName()
Pass Arguments: -no-aa -targetlibinfo -domtree -loops -scalar-evolution -da
No Alias Analysis (always returns 'may' alias)
Target Library Information
Dominator Tree Construction
Natural Loop Information
Scalar Evolution Analysis
0x. Executing Pass 'Foo' on Module 'foo.ll'...
0x. Required Analyses: Natural Loop Information, No target
information, Dominator Tree Construction, Dependence Analysis, Scalar
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?
There are a few minor patches for problems/crashes encountered while doing
this experiment. I'll post them soon to llvm-commits for review.