[llvm] r208934 - Implement global merge optimization for global variables.

[Rafael Espíndola]

> I think this entire optimization has the wrong design, and I think I'd like
> you to revert this patch -- unless I'm mistaken of course. Let me explain
> why and you can decide to revert.

I reverted because of its use o GEPs with non-zero offsets, but now
that I read the patch I agree with Nick's concerns.

I also a bit confused by what is the advantage. It looks like the
objective is to turn two global variables into a single one and have
an alias that provides a way to get the old name.

This then lets codegen use the address difference between the two
produce better code in a function that accesses both variables.

But the code does not check if there is any function accessing both
variables that are being merged. In fact, it can merge in a variable
that is not used at all in the current module, right?

The problem with that is that it will prevent the linker (even with
LTO, unless it gets smarter) from dead stripping this variable. Is
this uncommon enough that checking for uses coming from the same
function was not considered profitable?

Also, I know your change was not responsible for it, but why is this
ARM or AARCH64 specific? It might not be as big a win on X86, but
putting two variables that a function uses next to each other would
also be a win there, no?

In any case, I hope to have a patch adding an explicit offset to
GlobalAlias out this weekend or very early next week.

Thanks,
Rafael