[llvm-commits] patch: teach deadargelim to work on externally visible functions!

Chris Lattner clattner at apple.com
Sun Jan 10 22:33:53 PST 2010


On Jan 10, 2010, at 8:59 PM, Rafael Espindola wrote:

>> Correct . It is a very expensive feature :-(
> 
> Thinking a bit about it. Probably the best way to fix this is
> 
> *) Generate that linkage on ELF if the visibility is not hidden or protected
> *) Add the "strong but overridable" linkage you proposed.

Sounds good.  How is it different than our current "weak" linkage?

> *) Consider making protected-and-dont-care-about-pointer-compare the
> default. That would improve out of the box performance of ELF DSOs (as
> compared to gcc) and the user could always use
> __attribute__((visibility ("default"))) or -fvisibility=default.

Yep, we could even add an attribute for this, so you could mark malloc as overiddable or whatever.

> *) As an extension, add a
> protected-and-dont-care-about-pointer-compare that would be similar to
> the current state but drop the @PLT

This is something that would be a useful extension in any case.  Right now we may miscompile this code in some cases: 

static const char x[] = "foo";
static const char y[] = "foo";
int test() { return x == y; } 

Because we (incorrectly) merge the x and y decls.  We don't want to merge user variables if they have their "address taken", but we do want to merge things like C string literals (char *X = "foo").

If we had an attribute "don't care about pointer equality" we could handle this correctly.

> How does this work on Darwin btw? Function pointers are not guaranteed
> to compare when crossing shared library boundaries?

On darwin you're not allowed to redefined something in a different dylib unless it is attribute(weak).  Darwin uses a "two level namespace".  This causes the static linker to resolve and remember which dylib a "use" comes from.  If a third dylib starts defining that symbol, the use will still get the correct definition from the original defining dylib.  This also makes dynamic symbol resolution more efficient at process start time.

-Chris



More information about the llvm-commits mailing list