John Criswell via llvm-dev
2016-Mar-20 19:53 UTC
[llvm-dev] [GSoC 2016] Need more info on Add a MachineModulePass
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).> > 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). Regards, John 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/20160320/03c807b2/attachment.html>
Quentin Colombet via llvm-dev
2016-Mar-21 21:25 UTC
[llvm-dev] [GSoC 2016] Need more info on Add a MachineModulePass
> On Mar 20, 2016, at 12:53 PM, John Criswell <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? Thanks, -Quentin> > Regards, > > John Criswell > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochester > http://www.cs.rochester.edu/u/criswell <http://www.cs.rochester.edu/u/criswell>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160321/f63ff252/attachment.html>
John Criswell via llvm-dev
2016-Mar-21 21:39 UTC
[llvm-dev] [GSoC 2016] Need more info on Add a MachineModulePass
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>