llvm dev - Oct 2008 - [LLVMdev] merging globals

On Oct 15, 2008, at 7:34 PM, Eli Friedman wrote:
> This bug actually manifests itself in two places: one is
> ConstantMerge, the other is the AsmPrinter.  It's non-trivial to fix
> because it's really a design bug: we assume that constant==mergeable,
> which simply isn't true.  There are a few different ways of fixing
> this; however, I think the only real option is to add a new
> "mergeable" linkage type.
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.

-Chris

On Wed, Oct 15, 2008 at 11:09 PM, Mike Stump <mrs at apple.com>
wrote:
> 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.
Hmm... so the issue is that it's good for codesize to merge objects
with static duration that are marked in the source as const in
C/ObjC/C++, even when we can't prove it's correct?  That sounds
generally reasonable, although it would be mildly surprising for
anyone coding according to the standard.

It doesn't really change the issue, though; we want the merging to be
a front-end option, and we still need a solution which handles
variables that gets marked by the optimizer.

-Eli