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

Hi Quentin,
> On 22 Jan 2016, at 15:16, Quentin Colombet <qcolombet at apple.com>
wrote:
> 1. If anyone else is interested for such concept?
yes, we are! (https://github.com/t-crest)
> 2. What kind of information should we make accessible in an hypothetical
MachineModule? I.e., how do you plan to use the MachineModulePass so that we
make the right design decisions for the MachineModule feeding those passes?
we are building a toolchain for real-time systems, including optimizations and
analyses that deal with the machine-level code of entire real-time 
applications.

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.

I can walk you trough our code and give you feedback on things that we ran 
into, if you like.


ideally, the IR-level and the machine-level passes should (more or less) 
behave the same. I would also plan ahead and allow modifications to modules
(add/remove functions, global variables, ...). sooner or later people will want
to do this, once machine module passes are available.


best,
Florian

Hi Florian,
> On Jan 25, 2016, at 1:31 AM, Florian Brandner <florian.brandner at
telecom-paristech.fr> wrote:
> 
> Hi Quentin,
> 
>> On 22 Jan 2016, at 15:16, Quentin Colombet <qcolombet at
apple.com> wrote:
>> 1. If anyone else is interested for such concept?
> 
> yes, we are! (https://github.com/t-crest)
> 
>> 2. What kind of information should we make accessible in an
hypothetical MachineModule? I.e., how do you plan to use the MachineModulePass
so that we make the right design decisions for the MachineModule feeding those
passes?
> 
> we are building a toolchain for real-time systems, including optimizations
and
> analyses that deal with the machine-level code of entire real-time 
> applications.
Sounds interesting!
> 
> 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 can walk you trough our code and give you feedback on things that we ran 
> into, if you like.
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?
Do you have an example of MachineModulePass?
> 
> 
> ideally, the IR-level and the machine-level passes should (more or less) 
> behave the same. I would also plan ahead and allow modifications to modules
> (add/remove functions, global variables, ...). sooner or later people will
want
> to do this, once machine module passes are available.
Agreed.

Cheers,
-Quentin
> 
> 
> best,
> Florian
> 
>

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