[LLVMdev] merging globals

[Mike Stump]

On Oct 15, 2008, at 10:11 PM, Chris Lattner wrote:
> Eli, I don't disagree with you on any specific detail here.  I think
> there are decent solutions to this if anyone cares enough.  My only
> point is that this is an existing problem with other compilers.  On
> darwin, for example, x and y can get the same address, because x and y
> end up in the 'cstring' section which is coalesced by the linker:
>
> static const char x[] = "foo";
> static const char y[] = "foo";
> void *X() { return x; }
> void *Y() { return y; }
>
> This is clearly invalid, and a well known problem.  I agree that
> neither LLVM nor GCC should not do this, however, noone has cared
> enough to fix it yet.  If anyone cares enough to do so, I'm happy to
> help discuss various design points: I don't think this is very
> difficult.

Actually, we do this on purpose.  It is a huge win for us and we don't  
want to not do this, even if that means not exactly conforming to the  
standard.

Essentially, we wish the standard had chosen otherwise.  gcc handles  
this choice like this:

@item -fmerge-all-constants
Attempt to merge identical constants and identical variables.

This option implies @option{-fmerge-constants}.  In addition to
@option{-fmerge-constants} this considers e.g.@: even constant  
initialized
arrays or initialized constant variables with integral or floating point
types.  Languages like C or C++ require each non-automatic variable to
have distinct location, so using this option will result in non- 
conforming
behavior.

In reality, we should handle this by setting flag_merge_constants = 2  
in darwin.c, and documenting it.  All code that does merging should be  
testing flag_merge_constants and respecting it.  People that don't  
want merging are then free to turn it off.  It is this experience that  
gives rise to the idea that changing the standard to merge would not  
be a bad idea.  If they did this, then we wouldn't even need the flag,  
well, wouldn't need it except for legacy code.  Internally, one would  
still want it to support previous language standards.