[llvm-dev] [GlobalISel][RFC] Thoughts on MachineModulePass

[Florian Brandner via llvm-dev]

Hi Quentin,

On Monday 25 January 2016 13:47:17 Quentin Colombet wrote:
> > On Jan 25, 2016, at 1:31 AM, Florian Brandner <florian.brandner at telecom-paristech.fr> wrote:
> > we have implemented MachineModulePasses based on LLVM 3.4 (see the patmos-llvm
> > repository of T-CREST). it is clearly not a final solution for wide-spread 
> > use, but it works with a few limitations. for instance, it is difficult to 
> > preserve analysis information and access it in a machine module pass. similarly, 
> > it is rather difficult to pass information from a machine module pass back to 
> > function passes. we currently, work around this using ImmutablePasses.
> 
> Is there a chance you could port your changes for MachineModulePass for ToT?

I don't think that this would be useful. it really is not a solution that you 
should adopt on the long run (see below for an explanation).
 
> > I can walk you trough our code and give you feedback on things that we ran 
> > into, if you like.
> 
> Do you have an example of MachineModulePass?

we have several: 
- PatmosCallGraphBuilder: builds a machine-level call graph (including, for 
instance, floating-point emulation functions that are not visible on the 
IR-level).
- PatmosStackCacheAnalysis: performs an inter-procedural analysis on the usage
of a special cache for stack data

PatmosStackCacheAnalysis depends on the call graph -- which works just like
module passes on the IR. however, we cannot directly hand the analysis 
information to subsequent function passes. we use the immutable pass 
PatmosStackCacheAnalysisInfo for that.

the stack cache analysis is instantiated just as regular passes in the usual 
target machine (PatmosTargetMachine in this case).

> I see in your repository that you are still passing a Module to the module pass instead of a hypothetical MachineModule.
> How do you access each machine function in the module then?

that's right. we do this through the MachineModuleInfo class. we added a map 
from IR function to machine-level functions. this allows us to store the 
machine functions and later find them again.

this is where the hackish parts begin. the MachineFunctionAnalysis object that
would normally store the machine function until the end of the code generation,
is destroyed when a machine module pass runs (in fact all function passes are 
destroyed). later a new machine function analysis is recreated on the fly. we 
modified it to retrieve the function from the machine machine module info.

for our target, this works. since we do not keep information around in 
function passes. but quite a few other targets do. this information would be 
lost. there is no easy fix to this problem. function passes and module passes
are just not made to work together in that way. 

I remember that the IR-level pass infrastructure was redesign recently, but, if 
I recall correctly, the machine-level was explicitly excluded from this. did 
that that change? if not, you need to fix the way the pass managers and passes 
in general work in the backend before implementing machine module passes.



maybe we can find a couple of minutes for a call? that's long overdue 
anyways ;-)

best,
Florian