This is an archive of the discontinued LLVM Phabricator instance.

[builtins] Use aliases for function redirects
ClosedPublic

Authored by phosek on Apr 19 2019, 6:46 PM.

Details

Summary

Symbol aliases are supported by all platforms that compiler-rt builtins
target, and we can use these instead of function redirects to avoid the
extra indirection.

This is part of the cleanup proposed in "[RFC] compiler-rt builtins
cleanup and refactoring".

Diff Detail

Event Timeline

phosek created this revision.Apr 19 2019, 6:46 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptApr 19 2019, 6:46 PM
Herald added subscribers: llvm-commits, Restricted Project, aheejin. · View Herald Transcript

@mstorsjo the alias implementation is the same as the one used in D59921 (except we're not using weak aliases in this case), can you check that this looks okay to you?

echristo accepted this revision.Apr 19 2019, 6:47 PM
This revision is now accepted and ready to land.Apr 19 2019, 6:47 PM
phosek updated this revision to Diff 195955.Apr 19 2019, 6:49 PM
phosek updated this revision to Diff 195956.

Works fine for mingw setups.

However, the alias mechanism used for MSVC, alternatename directives, doesn't quite work the right way for compiler-rt. If the object file containing the alternatename directive hasn't been brought in by some other symbol, the linker won't find the alias symbol at all.

Normally, I would presume that compiler-rt builtins aren't used in MSVC style builds though, but I'm not sure if we want to exclude them outright either. Reid, do you have opinions or creative ideas? (Afaik, the gnu alias attribute will work with clang-cl, but not with MSVC proper.)

rnk added a comment.Apr 23 2019, 3:56 PM

However, the alias mechanism used for MSVC, alternatename directives, doesn't quite work the right way for compiler-rt. If the object file containing the alternatename directive hasn't been brought in by some other symbol, the linker won't find the alias symbol at all.

Normally, I would presume that compiler-rt builtins aren't used in MSVC style builds though, but I'm not sure if we want to exclude them outright either. Reid, do you have opinions or creative ideas? (Afaik, the gnu alias attribute will work with clang-cl, but not with MSVC proper.)

The best alternative to /alternatename: that I could find is /export:fn1=fn2, but it suffers from the same problem: fn1 isn't in the symbol table, so it won't be found if the object is in an archive. I'm surprised MSVC doesn't have a way to do this, since it's quite representable in COFF.

I think you're right, none of these aliases are needed on Windows. They are all for aebi compat or libgcc compat. Maybe the best thing to do would be to define the macro to nothing in the defined(_WIN32) case.

phosek updated this revision to Diff 196701.Apr 25 2019, 12:35 PM
In D60931#1476367, @rnk wrote:

However, the alias mechanism used for MSVC, alternatename directives, doesn't quite work the right way for compiler-rt. If the object file containing the alternatename directive hasn't been brought in by some other symbol, the linker won't find the alias symbol at all.

Normally, I would presume that compiler-rt builtins aren't used in MSVC style builds though, but I'm not sure if we want to exclude them outright either. Reid, do you have opinions or creative ideas? (Afaik, the gnu alias attribute will work with clang-cl, but not with MSVC proper.)

The best alternative to /alternatename: that I could find is /export:fn1=fn2, but it suffers from the same problem: fn1 isn't in the symbol table, so it won't be found if the object is in an archive. I'm surprised MSVC doesn't have a way to do this, since it's quite representable in COFF.

I think you're right, none of these aliases are needed on Windows. They are all for aebi compat or libgcc compat. Maybe the best thing to do would be to define the macro to nothing in the defined(_WIN32) case.

Done

Looks good from my perspective at least

This revision was automatically updated to reflect the committed changes.