search for: machineblockfrequ

...gister allocator’s live range splitting algorithm is > designed to consume profile information so it can push spill code into cold > blocks. The primary interface is SpillPlacement::getBlockFrequency() which > currently returns an estimate based on loop depth only. > It doesn't use MachineBlockFrequency? If it does, it will get a lot more than loop depth: __builtin_expect, cold function attribute, and static branch heuristics. If it doesn't it should, and then it will immediately benefit from this. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://l...

...greedy register allocator’s live range splitting algorithm is designed to consume profile information so it can push spill code into cold blocks. The primary interface is SpillPlacement::getBlockFrequency() which currently returns an estimate based on loop depth only. > > It doesn't use MachineBlockFrequency? If it does, it will get a lot more than loop depth: __builtin_expect, cold function attribute, and static branch heuristics. If it doesn't it should, and then it will immediately benefit from this. It predates the block frequency interface. It just needs to be hooked up, patches welcome....

On Jun 12, 2013, at 2:23 PM, Diego Novillo <dnovillo at google.com> wrote: > In terms of optimizations, our (Google) experience is that > inlining is the key beneficiary of profile information. > Particularly, in big C++ applications. I expect to focus most > of my attention on the inliner. That sounds plausible to me. It seems like we might need a way of representing call

I have started looking at the state of PGO (Profile Guided Optimization) in LLVM.**I want to discuss my high-level plan and make sure I'm not missing anything interesting out. I appreciate any feedback on this, pointers to existing work, patches and anything related to PGO in LLVM. I will be keeping changes to this plan in this web document