[llvm-dev] RFC: We should stop merging allocas in the inliner
David Majnemer via llvm-dev
llvm-dev at lists.llvm.org
Tue Aug 2 17:38:36 PDT 2016
On Tue, Aug 2, 2016 at 5:33 PM, Chandler Carruth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> FYI, I ran some initial measurements just for sanity on the test-suite on
> x86-64:
>
> Total stack frame size: 13362520 -> 13365864 (+0.02%)
> Average stack frame size: 581.814 -> 581.96 (+0.02%)
> Average compile time: 5.71178 -> 5.67256 (within noise)
>
Could you share the median stack frame sizes?
>
> Number of functions is exactly the same, so no trivially visible inlining
> decision changes.
>
> I've spot checked a few of the functions that had significant change in
> stack size. One shows a pattern that isn't too surprising in retrospect:
> this change allows us to hoist more code which causes live ranges to expand
> and increases spills. Nothing really scary here, and in many ways validates
> the core premise -- this does actually remove barriers to the mid-level
> optimizer.
>
> I've also found one case where stack coloring appears to just fail for no
> reason: "NArchive::N7z::GetStringForSizeValue(unsigned int)" in
> 7zHandler.cpp has exactly the same sequence of instructions after the
> change but 3x larger stack. But this appears to be rare and mostly relating
> to functions with already small stack sizes. I've filed PR28821 to track
> this.
>
> Anyways, while clearly some stuff will need cleaning up, I don't see
> anything really scary jumping out here.
>
> -Chandler
>
> On Tue, Aug 2, 2016 at 1:02 AM Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> Seeing no big concerns raised with this direction...
>>
>> On Sun, Jul 31, 2016 at 9:47 PM Chandler Carruth <chandlerc at gmail.com>
>> wrote:
>>
>>> 1) Add a flag to turn this off.
>>>
>>
>> https://reviews.llvm.org/D23052
>>
>> Will proceed from there.
>>
>> 2) Run benchmarks with flag to make sure things are actually working.
>>> 3) Change default for the flag, make sure chaos doesn't ensue.
>>> 4) Delete the (quite substantial) complexity associated with this and
>>> the flag.
>>> 5) Profit!
>>>
>>> -Chandler
>>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160802/9c344f9d/attachment.html>
More information about the llvm-dev
mailing list