[cfe-commits] r123192 - in /cfe/trunk: lib/CodeGen/CodeGenModule.cpp test/CodeGen/blocksignature.c test/CodeGen/const-init.c test/CodeGen/darwin-string-literals.c test/CodeGen/func-in-block.c test/CodeGen/predefined-expr.c test/CodeGen/string-literal-short-wstring.c test/CodeGen/string-literal.c test/CodeGenCXX/predefined-expr.cpp test/CodeGenObjC/predefined-expr.m

[Rafael Ávila de Espíndola]

>> The high level argument is that the address not being significant
>> is not a useful knowledge when all you have is a declaration. There
>> is nothing you can do to influence the address for example. This is
>> unlike knowing that a declaration is constant for example, since
>> you can use the constantness in optimizations.
>
> I agree that it isn't very useful, but it does make sense.  The C++
> frontend knows that the external rtti info for "int" is unnamed_addr,
> for example.

yes, but what would LLVM do with this information? The FE knows a lot 
more than it tells LLVM. I am not sure what the design principle is for 
what should be passed down other than information that is useful for 
optimizing.

>> Allowing them on declaration also means that we have to worry about
>> merging them during linking. What combinations should be valid?
>
> Merge to the value with the least information.  If one say it is
> named and one says it is unnamed, be pessimistic and assume named.
> Since the two translation units could be written in different
> languages (one may not have pointer comparison for example) we have
> to do this.

I got to a similar conclusion about merging two definitions (see 
previous email). Not so sure about declarations (in case we decide to 
allow unnamed_addr in them).

Consider the case:

* module 1 has a declaration of foo without unnamed_addr
* module 2 has a definition of foo with unnamed_addr
* module 3 has a definition of bar with unnamed_addr

Module 1 can legally do pointer comparisons with foo and assume it is 
unique. We now link 2 and 3 and combine foo and bar since they are found 
to be constants and equal.

If we allow unnamed_addr on declarations, we should probably error if a 
declaration without it resolves to a definition with it.

In fact, maybe being able to detect this error is a good reason for 
adding unnamed_addr to declarations :-)

> -Chris

Cheers,
Rafael