[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