llvm dev - Jan 2018 - PM: loop pass depending on the "outer" BPI analysis

Recently I was looking into porting IRCE loop pass into the new pass 
manager and stumbled on a problem.
The problem is due to the existing hard dependency of IRCE on 
BranchProbability analysis.

If I understand it right, in a new pass manager there are only two ways 
for loop analysis to ask
for the result of an "outer" (function/module-level) analysis:
   - get it from a predefined LoopStandardAnalysisResults set
     BPI is not there, so it unsuitable for me right now

   - query a cached result via getCachedResult of an outer analysis 
manager proxy
     only works if somebody already scheduled the analysis

I followed the cached-result way and that essentially means that for 
every presence of 'irce' in a pipeline
I have to insert 'require<branch-prob>' before it. It does not
look like
a very efficient approach.

In particular, all the IRCE tests use some variance of "opt -irce 
test.ll" invocation, which does not
work with a direct translation to "opt -passes=irce test.ll".
It only works with explicit
   opt -passes='require<branch-prob>,irce' test.ll

Legacy pass manager version of IRCE does have an explicit dependency on 
BranchProbabilityInfoWrapperPass
and that automatically installs that analysis into the pipeline before irce.

How do I express that kind of dependency with new pass manager?

If I did not miss something obvious that already handles these kinds of 
dependencies
then what should be the best way to go?

- Add BPI to LoopStandardAnalysisResults?
   This makes it a required analysis for all loop passes...

- Make it optional in LoopStandardAnalysisResults (similar to MSSA)?
   Then how to express the dependency when required?

- enhance FunctionToLoopPassAdaptor to allow extra passes being added 
into smth like LoopCanonicalizationFPM?

Please, advise.

thanks,
   Fedor.

On 01/26/2018 11:37 PM, Fedor Sergeev via llvm-dev wrote:
 > Recently I was looking into porting IRCE loop pass into the new pass 
manager and stumbled on a problem.
 > The problem is due to the existing hard dependency of IRCE on 
BranchProbability analysis.
 >
 > If I understand it right, in a new pass manager there are only two 
ways for loop analysis to ask
 > for the result of an "outer" (function/module-level) analysis:
 >   - get it from a predefined LoopStandardAnalysisResults set
 >     BPI is not there, so it unsuitable for me right now
 >
 >   - query a cached result via getCachedResult of an outer analysis 
manager proxy
 >     only works if somebody already scheduled the analysis
 >
 > I followed the cached-result way and that essentially means that for 
every presence of 'irce' in a pipeline
 > I have to insert 'require<branch-prob>' before it. It does
not look
like a very efficient approach.
 >
 > In particular, all the IRCE tests use some variance of "opt -irce 
test.ll" invocation, which does not
 > work with a direct translation to "opt -passes=irce test.ll".
 > It only works with explicit
 >   opt -passes='require<branch-prob>,irce' test.ll

And even that fails to work since LoopCanonicalizationFPM includes 
LoopSimplify, which can easily
invalidate BPI results.

regards,
   Fedor.

 >
 > Legacy pass manager version of IRCE does have an explicit dependency 
on BranchProbabilityInfoWrapperPass
 > and that automatically installs that analysis into the pipeline 
before irce.
 >
 > How do I express that kind of dependency with new pass manager?
 >
 > If I did not miss something obvious that already handles these kinds 
of dependencies
 > then what should be the best way to go?
 >
 > - Add BPI to LoopStandardAnalysisResults?
 >   This makes it a required analysis for all loop passes...
 >
 > - Make it optional in LoopStandardAnalysisResults (similar to MSSA)?
 >   Then how to express the dependency when required?
 >
 > - enhance FunctionToLoopPassAdaptor to allow extra passes being added 
into smth like LoopCanonicalizationFPM?
 >
 > Please, advise.
 >
 > thanks,
 >   Fedor.
 >
 > _______________________________________________
 > LLVM Developers mailing list
 > llvm-dev at lists.llvm.org
 > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev