search for: heuristc

...not consider the possible cleanup) 3) recursive inlining is not supported 4) function with indirect branch is not inlined. What source construct does indirect branch instr correspond to ? variable jump? 5) fudge factor prefers functions with vector instructions -- why is that? 6) There is one heuristc used in inline-cost computation seems wrong: // Calls usually take a long time, so they make the inlining gain smaller. InlineCost += CalleeFI->Metrics.NumCalls * InlineConstants::CallPenalty; Does it try to block inlining of callees with lots of calls? Note inlining such a function only...

...like interpreter loops, which you don't usually want to inline. > 5) fudge factor prefers functions with vector instructions -- why is that? I'm guessing that vectorized instructions are an indicator that the function is a hotspot, and should therefore be inlined. > 6) There is one heuristc used in inline-cost computation seems wrong: > >   // Calls usually take a long time, so they make the inlining gain smaller. >   InlineCost += CalleeFI->Metrics.NumCalls * InlineConstants::CallPenalty; > Does it try to block inlining of callees with lots of calls? Note inlining >...

...t; > 4) function with indirect branch is not inlined. What source construct > does indirect branch instr correspond to ? variable jump? Right. It's for "goto *ptr;". Nick > 5) fudge factor prefers functions with vector instructions -- why is that? > > 6) There is one heuristc used in inline-cost computation seems wrong: > > > // Calls usually take a long time, so they make the inlining gain > smaller. > InlineCost += CalleeFI->Metrics.NumCalls * InlineConstants::CallPenalty; > > Does it try to block inlining of callees with lots of calls? N...

...ut it. I agree that it should be revisited. > 4) function with indirect branch is not inlined. What source construct does indirect branch instr correspond to ? variable jump? See: http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html for more details. > 6) There is one heuristc used in inline-cost computation seems wrong: > > // Calls usually take a long time, so they make the inlining gain smaller. > InlineCost += CalleeFI->Metrics.NumCalls * InlineConstants::CallPenalty; > > Does it try to block inlining of callees with lots of calls? Note inlini...

Hi, I'm trying to understand why MachineScheduler does a poor job in straight line code in cases like the one in the attached debug dump. This is on AMDGPU, an in-order target, and the problem is that the IMAGE_SAMPLE instructions have very high (80 cycle) latency, but in the resulting schedule they are often placed right next to their uses like this: 1784B %140:vgpr_32 =

...tion order unless performance is at stake, the bar for adding heuristics is high. Complicating the heuristics now also means making them harder to understand and improve in the future. I would like to see a general solution to scheduling for register pressure. I had plenty of ideas for more ad-hoc heuristcs within the bounds of list scheduling, but given that we haven't dominstrated the value of simple heuristics, I don't want to pursue anything more complicated. I think better solutions will have to transcend list scheduling. I do like to the idea of constraining the DAG prior to scheduling...

...pectation that the GenericScheduler heuristics are anywhere near as good as they can be over the universe of workloads, but changing those heuristiscs means checking in with current backend maintainers to be sure you're not regressing their benchmarks in the process. I haven't touched these heuristcs in 6 years, but several others have had a hand in it recently. > > -Andy >

...not inlined. What source construct >> does indirect branch instr correspond to ? variable jump? >> > > Right. It's for "goto *ptr;". > > Nick > > 5) fudge factor prefers functions with vector instructions -- why is that? >> >> 6) There is one heuristc used in inline-cost computation seems wrong: >> >> >> // Calls usually take a long time, so they make the inlining gain >> smaller. >> InlineCost += CalleeFI->Metrics.NumCalls * InlineConstants::CallPenalty; >> >> Does it try to block inlining of cal...

...gt; > > 4) function with indirect branch is not inlined. What source construct > does indirect branch instr correspond to ? variable jump? > > See: > http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html > > for more details. > > > 6) There is one heuristc used in inline-cost computation seems wrong: > > > > // Calls usually take a long time, so they make the inlining gain > smaller. > > InlineCost += CalleeFI->Metrics.NumCalls * > InlineConstants::CallPenalty; > > > > Does it try to block inlining of callee...

Hi Andy, We have done some experimental evaluation of the different schedulers in LLVM 3.3 (source, BURR, ILP, fast, MI). The evaluation was done on x86-64 using SPEC CPU2006. We have measured both the amount of spill code as well as the execution time as detailed below. Here are our main findings: 1. The SD schedulers significantly impact the spill counts and the execution times for many