[llvm] r220138 - [InstCombine] Do an about-face on how LLVM canonicalizes (cast (load

[Hans Wennborg]

On Tue, Nov 25, 2014 at 2:33 PM, Hans Wennborg <hans at chromium.org> wrote:
> On Tue, Nov 25, 2014 at 9:48 AM, Hans Wennborg <hans at chromium.org> wrote:
>> On Tue, Nov 25, 2014 at 2:13 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
>>>
>>> On Thu, Nov 20, 2014 at 11:19 AM, Hans Wennborg <hans at chromium.org> wrote:
>>>>
>>>> > The only fallout I've found so far from this change was SROA and I have
>>>> > fixed it to not be impeded by the different type of load. If you find
>>>> > more places where this change causes optimizations not to fire, those
>>>> > too are likely bugs where we are assuming that the type of pointers is
>>>> > "significant" for optimization purposes.
>>>>
>>>> This caused a 97 k binary size regression in Chromium. I'll try to
>>>> produce some diffs of how the code changed.
>>>
>>>
>>> What ever came of this? I know you were side-tracked on LVI, but I don't
>>> want to miss this.
>>
>> Hopefully that side track is done now :)
>>
>>> I've also landed the other half of this in r222748. This may have (sadly)
>>> papered over the issue, or exacerbated the issue, depending on the nature of
>>> the problem. Feel free to hit me up with examples of IR diff...
>>
>> I'll try to figure out what the status is today.
>
> Chrome is still bigger with ToT Clang than our previously used version
> :( I'm looking at one object file that regressed at r220138, and that
> is still unchanged on ToT.
>
> Preprocessed source attached, build command is:
>
>   clang++ -fstack-protector --param=ssp-buffer-size=4
> -fno-strict-aliasing -fvisibility=hidden -fPIC -pthread -m64
> -march=x86-64 -O2 -fno-ident -fdata-sections -ffunction-sections
> -funwind-tables -fno-exceptions -fno-rtti -fno-threadsafe-statics
> -fvisibility-inlines-hidden -w -std=gnu++11 -c
> /tmp/ash.resize_shadow_controller.ii -o a.o
>
> Sizes before and after your change, and at ToT:
>
>    text    data     bss     dec     hex filename
>    2626     184       0    2810     afa /tmp/220137.o
>    2853     184       0    3037     bdd /tmp/220138.o
>    2853     184       0    3037     bdd /tmp/222768.o
>
> I'll see if I can figure out anything from the diffs.

Attaching IR and asm diffs for one of the functions that has grown (46
bytes). The other functions have similar diffs since it's the same
loop getting inlined.

I'm not seeing anything obvious in the IR diff, besides casts and
loads happening in different order, but in the asm diff it looks like
the loop is being laid out pretty differently. I'm not sure why that's
happening though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.ll
Type: application/octet-stream
Size: 11071 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141125/031944e5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff.s
Type: application/octet-stream
Size: 4362 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141125/031944e5/attachment-0001.obj>