[llvm-commits] [patch] Enable unnamed_addr in declarations again

Rafael Ávila de Espíndola rafael.espindola at gmail.com
Fri Jan 14 23:29:48 PST 2011


> I don't see what makes the weak def'n exemption correct. If the weak
> global is used in ways where its address matters, but the strong global
> isn't, linking them would produce uses of the strong global where the
> address matters. What am I missing?

If the linker is deciding to keep an unnamed_addr or a non unnamed_addr 
definition, it is possible that you have already lost. Consider the case:

* module 1 has strong const unnamed_addr symbol foo and an internal 
unnamed_add const bar with the same init as foo
* module 2 has weak symbols foo and its address matters

We optimize 1 and constmerge does its job and bar is merged with foo. We 
now link 1 and 2, and 2's assumptions are already wrong.

It is for an analogous reason that I was proposing to not special case 
declarations, but maybe the correct thing to do is to be really strict 
and disallow the replacement of regular symbols with unnamed_addr ones.

A unnamed_addr reference or weak symbol could be replaced with a non 
unnamed_addr definition, but not the other way around since making the 
resulting symbol non unnamed_addr now might be too late.

Sounds reasonable?

> Otherwise it sounds correct!
>
> Nick

Cheers,
Rafael



More information about the llvm-commits mailing list