search for: machinemodulepass

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 m...

...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...

...s 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 lay...

Hi, [Apologies to those receiving this mail twice - used the old list address by accident] In LLVM it is currently not possible to write a Module-level pass (a pass that modifies or analyzes multiple MachineFunctions) after DAG formation. This inhibits some optimizations[1] and is something I'd like to see changed. The problem is that in the backend, we emit a function at a time, from DAG

Hello, Probably this may be too late to start thinking about this project but I think this is particularly useful feature for LLVM. 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

...everything, ..." - Well, we've long-since succumb to that temptation when we LTO. C'est la vie. +1 as well, our LTO will benefit naturally from the leaf-to-root information propagation. ThinLTO will be more challenging/interesting though! > For the first part a mechanism similar to MachineModulePass would be desirable but that may not be possible during this project, but if we can make some sort of smaller version of that to suit our purpose. > I don't think we need to make any kind of MachineModulePass to make this work. Once we alter the visitation order based on the CGSCC iteration s...

...t two lists includes an estimate of the number of times the procedure is called or the variable is referenced in each execution of this procedure 2) Can llvm write informative commands to object files? 3) Can LTO is capable of leveraging those commands? For the first part a mechanism similar to MachineModulePass would be desirable but that may not be possible during this project, but if we can make some sort of smaller version of that to suit our purpose. 3) Compile time ----- Minimum cost interprocedural register allocation - http://dl.acm.org/citation.cfm?id=237780 4) Compile time ----- Register alloc...

*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. >

...ne is fundamentally opposed to this. > > > Not necessarily. I think that any information that isn't being serialized in MI right now for a function could be as well. Definitely something for GlobalISel to keep in mind. +1. That’s basically where I would like to go with MachineModule/MachineModulePass. http://lists.llvm.org/pipermail/llvm-dev/2016-January/094426.html Cheers, -Quentin > > I should note, a couple of issues have come up in the prototype. > - llvm::getDISubprogram was walking the function body to find the subprogram. This is trivial to fix as functions now have !dbg on...

Hi, I am Om Shivom and i am interested in adding a new pass in llvm in gsoc. I stumbled upon adding the MachineModulePass on the Open projects list ( http://llvm.org/OpenProjects.html#machinemodulepass ). Can someone help me understand the project properly or point to sources where i can get help from? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/p...

...b to that temptation when we LTO. C'est la vie. >> >> >> +1 as well, our LTO will benefit naturally from the leaf-to-root >> information propagation. ThinLTO will be more challenging/interesting >> though! >> >> For the first part a mechanism similar to MachineModulePass would be >> desirable but that may not be possible during this project, but if we can >> make some sort of smaller version of that to suit our purpose. >> >> I don't think we need to make any kind of MachineModulePass to make this >> work. Once we alter the visitat...

Hello everyone, As I mentioned in my previous posts,I am using a machinefunction pass to find all the loops in the program and do some analysis on them. I have completed my pass now and it works correctly. but the only issue is that,I have noticed that if I have two functions in my program, and one of them is part of the loop for another one ,by using runonmachinefunction(), I will get one loop

...A among others depends on seeing the IR at query time. We'd need to work out a way of providing alias analysis with no IR present. I don't think that is feasible for the near future. So my suggestion is that we go with Matthias' idea - do the small amount of refactoring needed to allow MachineModulePasses on an opt-in basis. The knobs to enable that opt-in might need some more bikeshedding. Cheers, James On Tue, 19 Jul 2016 at 08:21 Justin Bogner <mail at justinbogner.com> wrote: > James Molloy via llvm-dev <llvm-dev at lists.llvm.org> writes: > > In LLVM it is currently n...

...h, but this is efficient only when you have the function definition that is codegen in the same module as the call site. So why LTO? Because you see "all" the definition for "all" the call sites in your program. -- Mehdi >> For the first part a mechanism similar to MachineModulePass would be desirable but that may not be possible during this project, but if we can make some sort of smaller version of that to suit our purpose. >> I don't think we need to make any kind of MachineModulePass to make this work. Once we alter the visitation order based on the CGSCC iterati...

...LTO. C'est la vie. >>> >>> >>> +1 as well, our LTO will benefit naturally from the leaf-to-root >>> information propagation. ThinLTO will be more challenging/interesting >>> though! >>> >>> For the first part a mechanism similar to MachineModulePass would be >>> desirable but that may not be possible during this project, but if we can >>> make some sort of smaller version of that to suit our purpose. >>> >>> I don't think we need to make any kind of MachineModulePass to make this >>> work. Once...

...>>> >>>> >>>> +1 as well, our LTO will benefit naturally from the leaf-to-root >>>> information propagation. ThinLTO will be more challenging/interesting >>>> though! >>>> >>>> For the first part a mechanism similar to MachineModulePass would be >>>> desirable but that may not be possible during this project, but if we can >>>> make some sort of smaller version of that to suit our purpose. >>>> >>>> I don't think we need to make any kind of MachineModulePass to make >>>&...

...aviour, and the execution frequency of the code being outlined. In partucular, using a processor with heavy function call latency will likely increase execution time overhead. ================================ Implementation ================================ The outliner, in its current state, is a MachineModulePass. It finds *identical* sequences of MIR, after register allocation, and pulls them out into their own functions. Thus, it's effectively assembly-level. Ultimately, the algorithm used is general, so it can sit anywhere, but MIR was very convenient for the time being. It requires two data structu...

...- Well, we've long-since succumb to that temptation when we LTO. C'est la vie. >> >> +1 as well, our LTO will benefit naturally from the leaf-to-root information propagation. ThinLTO will be more challenging/interesting though! >> For the first part a mechanism similar to MachineModulePass would be desirable but that may not be possible during this project, but if we can make some sort of smaller version of that to suit our purpose. >> I don't think we need to make any kind of MachineModulePass to make this work. Once we alter the visitation order based on the CGSCC iterati...

...;>> >>>>> +1 as well, our LTO will benefit naturally from the leaf-to-root >>>>> information propagation. ThinLTO will be more challenging/interesting >>>>> though! >>>>> >>>>> For the first part a mechanism similar to MachineModulePass would be >>>>> desirable but that may not be possible during this project, but if we can >>>>> make some sort of smaller version of that to suit our purpose. >>>>> >>>>> I don't think we need to make any kind of MachineModulePass to ma...

...eFunctionPasses itself, and the ImmutablePasses need to be passed around in the PassManager properly). The downside is that the memory consumption will go up since the backend must now keep all MachineFunctions in memory instead of processing them one-by-one (I avoid this overhead as long as no MachineModulePass is used though). I also have not checked what happens if you remove or add functions in a module pass. I hacked this into our backend which is based on LLVM 3.2. There have been some changes to the way passes are initialized and finalized in 3.3, but I think most of my patches will be the same...