This is an archive of the discontinued LLVM Phabricator instance.

[clang][RelativeVTablesABI] Use dso_local_equivalent rather than emitting stubs
ClosedPublic

Authored by leonardchan on Jul 14 2020, 1:17 PM.

Details

Summary

Thanks to D77248, we can bypass the use of stubs altogether and use PLT relocations if they are available for the target. LLVM and LLD support the R_AARCH64_PLT32 relocation, so we can also guarantee a static PLT relocation on AArch64. Not emitting these stubs saves a lot of extra binary size.

Diff Detail

Event Timeline

leonardchan created this revision.Jul 14 2020, 1:17 PM
rjmccall added inline comments.Jul 17 2020, 11:07 AM
clang/lib/CodeGen/CGVTables.cpp
633

Could you add a method to TargetCodeGenInfo for this instead of hard-coding a list of architectures here?

leonardchan marked an inline comment as done.

Add a method to TargetCodeGenInfo the returns if the target supports PC relative PLT relocations,

rjmccall accepted this revision.Jul 21 2020, 10:31 AM

Thanks, LGTM.

This revision is now accepted and ready to land.Jul 21 2020, 10:31 AM
leonardchan retitled this revision from [clang][RelativeVTablesABI] Do not emit stubs for architectures that support a PLT relocation to [clang][RelativeVTablesABI] Use dso_local_equivalent rather than emitting stubs.
leonardchan edited the summary of this revision. (Show Details)

Update to use dso_local_equivalent instead of emitting stubs in the frontend. dso_local_equivalent should emit a stub automatically if one is required for the target (ie. it does not support PLTs).

Rebased.

@rjmccall This might've changed a bit since you last accepted the revision. Will wait a couple of days before submitting if you have any more comments on this.

This revision was landed with ongoing or failed builds.Nov 30 2020, 4:04 PM
This revision was automatically updated to reflect the committed changes.