[LLVMdev] ModulePass Strangeness and OnTheFly Pass Management

[Jason Kim]

cc'ing the usual suspects :-)



>
> 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
>
>
>
>