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

[John Criswell via llvm-dev]

On 3/21/16 5:25 PM, Quentin Colombet wrote:
>
>> On Mar 20, 2016, at 12:53 PM, John Criswell <jtcriswel at gmail.com 
>> <mailto:jtcriswel at gmail.com>> wrote:
>>
>> On 3/18/16 12:33 PM, Quentin Colombet via llvm-dev wrote:
>>> Hi Vivek,
>>>
>>>> On Mar 16, 2016, at 1:00 PM, vivek pandya via llvm-dev 
>>>> <llvm-dev at lists.llvm.org <mailto: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.
>>
>> I think this is a separate issue from having a MachineModulePass.  My 
>> goal in having a MachineModulePass is to be able to do 
>> inter-procedural analysis and transformation on a program after its 
>> code has been generated.  Examples of such applications include 
>> inter-procedural register allocation, inter-procedural instruction 
>> selection, inter-procedural code layout optimization (I have a 
>> colleague working on this using reference affinity theory), and 
>> inter-procedural analysis of machine code for measuring the efficacy 
>> of compiler transformations for security.
>>
>> Whether one keeps the LLVM IR around or not is orthogonal.  What is 
>> needed is a way of being able to examine the whole program without 
>> having to worry about another transformation running in parallel (if 
>> you use a MachineFunctionPass, as I understand it, the pass should 
>> not be analyzing/transforming other MachineFunction's).
>
> I agree. I was exposing my use case to help designing the whole thing. 
> Yes, it does not have to be addressed for the MachineModule to be 
> useable for other things.
>
>>
>>>
>>> One of the main challenge is about alias analysis information that 
>>> are tight with LLVM IR, but may be used in MachineFunctionPass.
>>
>> One of the other projects I proposed is to encode this information 
>> within the MachineInstr IR.  This would be very useful for one of my 
>> projects, and it might solve this problem as well (once the 
>> information is encoded in the MachineInstr IR, you don't need the 
>> LLVM IR around anymore).
>
> That sounds like a possible solution. Do you have a link to the thread 
> where this has been discussed?

It's a project idea that I added to the Open Projects page.  I don't 
think I've seen anyone volunteering to work on it on the mailing lists.

Regards,

John Criswell

>
> Thanks,
> -Quentin
>
>>
>> Regards,
>>
>> John Criswell
>>
>> -- 
>> John Criswell
>> Assistant Professor
>> Department of Computer Science, University of Rochester
>> http://www.cs.rochester.edu/u/criswell
>


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

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