<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 1, 2016, at 11:24 PM, Xinliang David Li <<a href="mailto:davidxl@google.com" class="">davidxl@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Tue, Nov 1, 2016 at 10:39 PM, Mehdi Amini<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><span class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 1, 2016, at 10:01 PM, Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank" class="">davidxl@google.com</a>> wrote:</div><br class="m_-1215484276421138568Apple-interchange-newline"><div class=""><br class="m_-1215484276421138568Apple-interchange-newline"><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;" class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">On Tue, Nov 1, 2016 at 8:06 PM, Mehdi AMINI<span class="m_-1215484276421138568Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:mehdi.amini@apple.com" target="_blank" class="">mehdi.amini@apple.com</a>></span><span class="m_-1215484276421138568Apple-converted-space"> </span><wbr class="">wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">mehdi_amini added a comment.<br class=""><br class="">(Add inline the answer to David, so that there is the relevant context)<br class=""><br class=""><br class=""><br class="">================<br class="">Comment at: lib/Analysis/InlineCost.cpp:93<wbr class="">8<br class="">- if (!isa<InlineAsm>(CS.getCalledV<wbr class="">alue()))<br class="">- Cost += InlineConstants::CallPenalty;<br class=""> }<br class="">----------------<br class=""><span class="">>>! In D24338, @davidxl wrote:<br class="">> Do you mean parameter passing? That should be counted independently by the instruction visitor.<br class=""><br class=""></span>No, I don’t mean the parameters, the visitor account for one instruction per parameter just before this indeed.<br class="">However a call has other extra-cost on top of a regular instruction, even without any argument: it splits live-ranges and may cause spills around it to preserve registers that aren't callee-saved.<br class=""><br class="">In this sense, it make sense that a call can "cost" more than a normal instruction.<br class=""></blockquote><div class=""><br class=""></div><div class="">yes, inlining can lead to increased register pressure leading to use of caller save registers (and spills around new callsites). However I think this should not be blindly applied -- better tied with register pressure analysis.</div></div></div></blockquote><br class=""></div></span><div class="">I’m not sure we’re talking on the same level here: I don’t claim the the register pressure will increase in the caller after inlining here, or at least not because of call instructions in the callee.</div><div class="">My assumption (possibly incorrect), is that the current inliner cost model trades off the cost of the call site with the increased code size resulting from the inlining.</div><div class=""><br class=""></div><div class="">When we consider the overall “cost” of a callee: we a cost per-instruction in the visitor. The question is what is this cost representing? From a code size point of view, it make sense to add a penalty for call instructions because they have potentially more impacts (spills is an example that is specific to calls).</div></div></blockquote><div class=""><br class=""></div><div class="">From the way it is currently implemented, it is likely the cost is to model the size increase. Yes, spills can result in size increase too -- but my point is that size cost of spills can not be unconditionally applied. </div><div class=""> </div><div class="">To compute runtime cost/benefit, the 'runtime cost diff's of the callee and inline instance of the callee needs to be computed (with the help of profile info). Easwaran has a speed-up analysis patch that does that.</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""><br class=""></div><div class="">I don’t believe the patch as-is demonstrate that removing this penalty is the right thing to do: I’d like to see first how it compares to:</div><div class="">1) simply starting by deducing the cost of one call (the call-site considered for inlining) ;</div></div></blockquote><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">it is included in this patch, but should be split and committed first: that’s mostly a “bug fix”.</div></div></blockquote><div class=""><br class=""></div><div class="">this sounds reasonable.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class="">2) simply increasing the threshold.</div><div class=""><br class=""></div></div></blockquote><div class="">This is a different tuning IMO.</div></div></div></blockquote><div><br class=""></div><div>I agree. The way I see this is some sort of “smoke test” for the measurement: if a minor bump to the threshold provides very similar results, you may question the conclusion based on these.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class=""><div class=""></div><div class="">Without these additional baseline, it is not clear to me that the measurement is sound: we can very well obtain better result because we will now inline a function that has multiple calls, while there can exist similar function without many calls but a bit more arithmetic that would also be profitable to inline.</div></div></blockquote><div class=""><br class=""></div><div class="">Or do this: split the current CallPenalty into two parameters:</div><div class="">* CallPenalty which is used in patch #1 you suggested -- i.e, the value to be deducted from the cost of callsite to be inlined</div><div class="">* CallInstrCost -- this value is used to model the 'size cost' of call instruction (which considers potential spilling code). The value can be tuned independently -- lowed below 25 but higher than 5 (the default instruction cost).</div></div></div></blockquote><br class=""></div><div>Yes, this is perfectly matching the model I have in mind.</div><div><br class=""></div><div>Thanks!</div><div><br class=""></div><div>— </div><div>Mehdi</div></body></html>