<div dir="ltr">FYI, searching the code base for getUserCost, I noticed getGEPCost is used in not only inlining but also loop unrolling and SimplifyCFG to compute speculation cost. </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 1:51 PM, Hans Wennborg <span dir="ltr"><<a href="mailto:hans@chromium.org" target="_blank">hans@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah, I didn't realize this feeds into the inlining cost. That makes<br>
sense. Thanks.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Sep 9, 2015 at 1:45 PM, Jingyue Wu <<a href="mailto:jingyue@google.com">jingyue@google.com</a>> wrote:<br>
> I guess this is because more functions are inlined.<br>
><br>
> This patch changes (improves IMO) how the cost of GEPs is computed. If a GEP<br>
> can be complete folded into an addressing mode, TTI reports its cost is<br>
> zero. Therefore, the cost of a function tends to be smaller than before,<br>
> causing more functions to be inlined and thus increasing the binary size.<br>
><br>
> On Wed, Sep 9, 2015 at 1:26 PM, Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br>
>><br>
>> (cc'ing the new list; sorry for the duplicate email)<br>
>><br>
>> On Wed, Sep 9, 2015 at 1:24 PM, Hans Wennborg <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br>
>> > On Sun, Jul 26, 2015 at 12:10 PM, Jingyue Wu <<a href="mailto:jingyue@google.com">jingyue@google.com</a>> wrote:<br>
>> >> Author: jingyue<br>
>> >> Date: Sun Jul 26 14:10:03 2015<br>
>> >> New Revision: 243253<br>
>> >><br>
>> >> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=243253&view=rev" rel="noreferrer" target="_blank">http://llvm.org/viewvc/llvm-project?rev=243253&view=rev</a><br>
>> >> Log:<br>
>> >> Roll forward r243250<br>
>> >><br>
>> >> r243250 appeared to break clang/test/Analysis/dead-store.c on one of<br>
>> >> the build<br>
>> >> slaves, but I couldn't reproduce this failure locally. Probably a false<br>
>> >> positive as I saw this test was broken by r243246 or r243247 too but<br>
>> >> passed<br>
>> >> later without people fixing anything.<br>
>> ><br>
>> > This caused a 150 KB binary size increase in Chromium. Is that expected?<br>
>> ><br>
>> > I'm not familiar with this code, but from my reading of the change<br>
>> > description, it sounds more like it should decrease size by folding<br>
>> > more address computations into mov instructions?<br>
><br>
><br>
</div></div></blockquote></div><br></div>