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

Marcello Maggioni via llvm-dev llvm-dev at lists.llvm.org
Sat Jan 23 16:16:58 PST 2016


Yeah, the features needed would probably match pretty closely to what an IR Module Pass would do 
It is funny that you mentioned the AsmPrinter, because that is actually where one of our hacks lives right now, as it is the last thing that happens and always executes, it can be used to collect and accumulate statistics or emit binary metadata for groups of functions when it is detected that a bunch of related functions has been already processed.

Another use for a “transformation” module pass is global allocation of resources and insertion of resource handling of these resources at machine level. If we have multiple functions then being able to do the allocation on all of them at once could potentially have an advantage over doing them one at a time without information on the others (because synchronization needs in that case to consider the worst case scenario).
A MachineModulePass could be a natural candidate to do something like that.

Having something that can modify functions, blocks and instructions would be enough for these cases, but having something more powerful (adding machinefunctions in the pipeline) maybe could also be useful.

Marcello
> On 23 Jan 2016, at 11:33, Eric Christopher <echristo at gmail.com> wrote:
> 
> Hi Marcello,
> 
> Can you elaborate here a bit more? Mostly what it sounds like is just a direct port of Module pass to run over MFs, similar to what AsmPrinter does today, but also being able to have some analysis passes as well?
> 
> I realize my question seems a bit vague, but I'm trying to get a better idea of what the use case is here as it sounds like something that we could have the "MF pipeline" have and use and be (possibly) a better place to stick the AsmPrinter (we'd need to figure out things like globals, but that might be it).
> 
> Thanks!
> 
> -eric
> 
> On Fri, Jan 22, 2016 at 10:44 PM Marcello Maggioni via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> The pass, the perspective of our use case, would need to be able some kind of synchronization point in the pipeline between MF passes (such that all the MF passes before have run on all the MachineFunctions in the Module before running the MachineModule pass)
> Currently the MachineFunctions are processed from the beginning to the end making it difficult to be able to do Machine level analysis without awful tricks (where we get information from multiple functions and merge them together in some way).
> Immutable passes would also need to be accessible.
> 
> An important design decision would be to understand what can and cannot a MachineModulePass do to a hypotetical MachineModule (can it add MachineFunctions that are not connected to IR machine functions like a MachineFunction pass can add MachineBasicBlocks not connected to IR BasicBlocks?)
> 
> Marcello
> 
> > On 22 Jan 2016, at 15:16, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
> >
> > Hi,
> >
> > In the initial thread of the proposal for GlobalISel, I have mentioned that it may be interesting to have a kind of MachineModulePass.
> > Marcello mentioned this would be useful for their current pipeline.
> >
> > I am interested in knowing:
> > 1. If anyone else is interested for such concept?
> > 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?
> > 3. Who would be willing to work on that?
> >
> > Thanks,
> > -Quentin
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160123/b0304d6b/attachment.html>


More information about the llvm-dev mailing list