This is an archive of the discontinued LLVM Phabricator instance.

[lto] Kill undefined extern_weak declarations before opt
Needs ReviewPublic

Authored by eugenis on Oct 20 2016, 5:26 PM.

Details

Reviewers
pcc
Summary

If an extern_weak declaration is resolved as undefined, RAUW it with
a null pointer and remove it from the module before running LTO
optimizations.

Besides the obvious codegen improvement, it allows CFI to avoid
generating jump tables for such functions (which can not be done
correctly, as a jump table entry can not be weak).

Diff Detail

Repository
rL LLVM

Event Timeline

eugenis updated this revision to Diff 75376.Oct 20 2016, 5:26 PM
eugenis retitled this revision from to [lto] Kill undefined extern_weak declarations before opt.
eugenis updated this object.
eugenis added a reviewer: pcc.
eugenis set the repository for this revision to rL LLVM.
eugenis added a subscriber: llvm-commits.
mehdi_amini added inline comments.Oct 20 2016, 5:35 PM
include/llvm/LTO/LTO.h
469

Add that it is only valid for extern_weak

lib/LTO/LTO.cpp
253

This logic isn't clear to me, mostly because it is testing redundant thing.
We should not allow Res.Undefined to be used with a non extern_weak, so I expect some error handling instead.

475

Comment.

pcc added inline comments.Oct 20 2016, 5:44 PM
include/llvm/LTO/LTO.h
428

Do we need to track this globally?

lib/LTO/LTO.cpp
346

I would have thought that you could keep track of the undefined symbols in a local variable here and RAUW them in a loop below. That way, you can avoid the global tracking.

mehdi_amini added inline comments.Oct 20 2016, 6:05 PM
lib/LTO/LTO.cpp
346

How do you address ThinLTO?

Which needs to be added to the patch BTW.

pcc added inline comments.Oct 20 2016, 6:27 PM
lib/LTO/LTO.cpp
346

How do you address ThinLTO?

The way I see this feature eventually being added to ThinLTO is:

  • decouple LLVM linkages from ThinLTO summary linkages
  • (orthogonally: represent "drop" as another type of linkage -- this would allow us to drop unchosen linkonce or weak (non-odr) definitions)
  • add a new "linkage" (at this point we can probably call it a resolution) which represents an undefined extern_weak.
  • copy all resolution information into the summary during addThinLTO while handling each input file (during mergeFrom or thereabouts)

Which needs to be added to the patch BTW.

It doesn't seem necessary to do so in the first patch. This is just an optimisation, and the CFI feature that relies on this does not (currently) work with ThinLTO. But @eugenis please do add a FIXME.

tools/llvm-lto2/llvm-lto2.cpp
68

Please update the documentation.

mehdi_amini added inline comments.Oct 20 2016, 6:32 PM
lib/LTO/LTO.cpp
346

The way I see this feature eventually being added to ThinLTO is [...]

Please send an RFC for such kind of changes.

It doesn't seem necessary to do so in the first patch.

I don't like this. One of the main reason I wanted a unified API is also exactly to avoid these kinds of discrepancies and designed these from the ground-up for LTO *and* ThinLTO.

mehdi_amini added inline comments.Oct 21 2016, 10:34 AM
lib/LTO/LTO.cpp
346

To clarify my position, I'm fine with an "incremental" patch, as long as we first validate a design that handle both, i.e. not having ThinLTO folks (including me) arriving after the fact and having to basically redo everything from scratch because the way it is done cannot integrate with ThinLTO.

It appears that this optimization is only possible in executables.

Extern_weak declarations can not be bound at link time when building a shared library, because any available definition is not final, and even the lack of any definition is not final.

This means that CFI will have to deal with undefined extern_weak declarations somehow, which makes this change only a minor optimization, so I'm going to drop it for now. I agree with the thinlto comments, and if I decide to work on this again, I'll start with an RFC.