[llvm-dev] [GSoC 2016] Need more info on Add a MachineModulePass

[vivek pandya via llvm-dev]

*Vivek Pandya*


On Sat, Mar 19, 2016 at 1:30 AM, Quentin Colombet <qcolombet at apple.com>
wrote:

>
> On Mar 18, 2016, at 12:38 PM, vivek pandya <vivekvpandya at gmail.com> wrote:
>
>
>
> *Vivek Pandya*
>
>
> On Fri, Mar 18, 2016 at 10:03 PM, Quentin Colombet <qcolombet at apple.com>
> wrote:
>
>> Hi Vivek,
>>
>> On Mar 16, 2016, at 1:00 PM, vivek pandya via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hello,
>>
>> Probably this may be too late to start thinking about this project but I
>> think this is particularly useful feature for LLVM.
>>
>>
>> +1. I’d like to use something this feature in GlobalISel. The idea is
>> that has as soon as we lowered the LLVM IR of the whole module to
>> MachineInstr, the LLVM IR should be deallocable.
>> In other words, the MachineModule/MachineFunctions should contain enough
>> information such that we do not have to keep the LLVM IR around.
>>
>> One of the main challenge is about alias analysis information that are
>> tight with LLVM IR, but may be used in MachineFunctionPass.
>>
>> A quick use I can think of this is Implementing Inter-procedural Register
>> Allocation ( for Research purpose ).
>>
>> I have start looking at the code for MachineFunctionPass, I think
>> currently MachineModule class is not available ( the project work will
>> include that ) but trying to find out required details to first create a
>> MachineModule class which holds references to required information. I am
>> also trying to figure out what are the things should compose MachineModule
>> class ( some sort of analogy with Module class used for IR passes)
>>
>>
>> At least for GlobalISel, we would need a way to create and get the global
>> variables of a Module, but lowered to MachineInstr (or MC) level.
>>
>> Looking at the current implementation of the Module class, it seems that
> Module class maintains Linked List to GlobalVariables, Functions,
> GlobalAliasis ... and meta informations about the Module like file name ,
> Module ID , Target Triple DataLayout etc.  And currently for
> MachineFunction pass MachineFunctionAnalysis creates object of
> MachineFunction. The MachineFunction constructor takes Function,
> TargetMachine etc as arguments and creates MachineBasicBlocks and thus
> provides access to MachineInstr.
>
> Now I have very rough idea to inherit the Module Pass and use the
> information available in Module class to create MachineModule class.
> MachineModule class should use MachineFunctionAnalysis to create
> MachineFunction for each Function F in Module class MachineModule class
> should create links between all these MachineFunction object as per the
> original linked list of Function objects. Similarly we need to get MC
> lowered representation for each features of Module class when it is
> possible and we should also preserve some IR Analysis that are useful at
> later stage.
> Then we provide various method to use this information (access
> GlobalVariable etc)  as similar to Module class. Once we have MachineModule
> class ready  we can use this to execute user specific operation on each
> function or provide user iterators for MachineFunction list.
>
> I think I need to look at how LLVM IR is lowered to MachineIR to
> understand this better.
>
>
> This part is the job of instruction selection. The machine instruction
> after ISel are pretty much standalone modulo some back link to the llvm ir
> for the memory addresses and such. Those same back links are used to query
> the alias analysis.
> The link to the Function from the MachineFunction is here to provide an
> access to Function attributes and other utilities. I believe we could
> transfer the ownership of those things as par of the lowering.
>

I found some great blog post on this topic
http://eli.thegreenplace.net/2012/11/24/life-of-an-instruction-in-llvm
Quentin Do you think the above mentioned plan is reasonable and  it would
work ?

>
> Please provide some more info or analysis so that I can build a reasonable
> and promising work plan for this.
>
> Sincerely,
> Vivek
>
>>
>> After that I think next step is to extend the ModulePass and let
>> ModulePass execute optimization provide enough information.
>>
>>
>> +1
>>
>>
>> Am I going in correct direction?
>>
>>
>> Yes, at least, it makes sense to me.
>>
>> Please provide some pointers.
>>
>>
>> Other than gathering feedback on what is needed and trying, I
>> unfortunately cannot offer anything else.
>>
>> Cheers,
>> -Quentin
>>
>>
>> Sincerely,
>> *Vivek Pandya*
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> 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/20160319/eb84fa5a/attachment.html>