Hi Quentin,
> 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