llvm dev - Mar 2014 - [LLVMdev] ModulePass Strangeness and OnTheFly Pass Management

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

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