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

[Hans Wennborg]

On Fri, Oct 17, 2014 at 11:36 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> Author: chandlerc
> Date: Sat Oct 18 01:36:22 2014
> New Revision: 220138
>
> URL: http://llvm.org/viewvc/llvm-project?rev=220138&view=rev
> Log:
> [InstCombine] Do an about-face on how LLVM canonicalizes (cast (load
> ...)) and (load (cast ...)): canonicalize toward the former.
>
> Historically, we've tried to load using the type of the *pointer*, and
> tried to match that type as closely as possible removing as many pointer
> casts as we could and trading them for bitcasts of the loaded value.
> This is deeply and fundamentally wrong.
>
> Repeat after me: memory does not have a type! This was a hard lesson for
> me to learn working on SROA.
>
> There is only one thing that should actually drive the type used for
> a pointer, and that is the type which we need to use to load from that
> pointer. Matching up pointer types to the loaded value types is very
> useful because it minimizes the physical size of the IR required for
> no-op casts. Similarly, the only thing that should drive the type used
> for a loaded value is *how that value is used*! Again, this minimizes
> casts. And in fact, the *only* thing motivating types in any part of
> LLVM's IR are the types used by the operations in the IR. We should
> match them as closely as possible.
>
> I've ended up removing some tests here as they were testing bugs or
> behavior that is no longer present. Mostly though, this is just cleanup
> to let the tests continue to function as intended.
>
> 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.

 - Hans