[LLVMdev] merging globals

[Mike Stump]

On Oct 16, 2008, at 1:57 PM, Eli Friedman wrote:
> I strongly doubt we can get away with that.

Yeah, we agree on that one.  I was just thinking about the const case.

> Here's a more concrete version of the solution I'm proposing: we add a
> new optional marking to constant globals, say "mergeable".  There are
> two reasonable semantics: one is that the result of equality
> comparisons of a pointer into this global with a pointer into any
> other similarly marked global is undefined.

undefined means the code is free to rm -rf /, is this what you meant?   
I'm against that.

The usual wording is sufficient:

   It is unspecified whether such a variable has an address distinct  
from that of any other object in the program

to reuse the concept and words from 8.4p8 (n2461).  This isn't quite  
right, but we know what is meant by it.  The implementation is free to  
merge it with any other mergable object.

> This has the following effects on current optimizers: constmerge only
> merges globals marked mergeable.  Only mergeable constants are emitted
> into mergeable sections in assembly.  If we use the conservative
> definition of mergeable, fix any code that assumes distinct globals
> don't get merged, like the code that folds equality comparisons
> between distinct globals to false.  Optionally, add a new optimization
> step which marks constants as mergable when their address isn't taken.

:-)  Sounds like a plan.