On Tue, Apr 22, 2014 at 1:17 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> This looks fine. LIPO has similar change too. Other directions worth >> looking into: >> >> 1) To model icache effect better, weighted callee size need to be >> used with profile. The weight for BB may look like: min(1, >> FREQ(BB)/FREQ(ENTRY)). >> 2) When function splitting is turned on, are any inline heuristic >> changes are needed? E.g. only consider the hot code part of node for >> unit growth computation? >> >> We are also looking into more aggressive approach to track per loop >> (inter-procedural) region growth limit, instead of using one single >> global limit. > > Per-loop growth seems interesting. I assume it is not hard to associate edges > with loop nests and it has more of a local nature.
per-function loop nests form a graph, which can be embedded inside the callgraph. One of the main thing is loop graph update (just like callgraph node/edge cloning), and summary data update during inlining. > Did you experiment with it? We currently do not have time for this, but you are welcome to experiment with it:) Related ideas: 1) per loop priority; 2) more precise code-reuse (icache locality), and icache/itlb penalty estimate; 3) more precise per loop register pressure estimate; 4) other loop transformation hints. thanks, David > > Honza
