This is an archive of the discontinued LLVM Phabricator instance.

[clang][compiler-rt] Support LLVM_ENABLE_PER_TARGET_RUNTIME_DIR on Arm Linux and BSD
ClosedPublic

Authored by DavidSpickett on Dec 14 2022, 4:20 AM.

Details

Summary

The orginal single folder layout produced libraries in the form:
lib/linux/<libname>-<archname>.a

That archname for Arm depended on whether you had hard or soft float.
This is sometimes shown as "arm" (soft) vs. "armhf" (hard).

If this is set in a triple we do it in the final portion, the ABI.
"gnueabi" for soft float, "gnueabihf" for hard float.

Meaning that the expected triple is:
arm-unknown-linux-gnueabihf
Not this:
armhf-unknown-linux-gnueabihf

For the per target layout I have decided to rely on the ABI portion
of the triple instead of the arch name used for the old layout
(doing that would produce the invalid triple above).

This means that building with triple:
armv8l-unknown-linux-gnueabihf
Will result in libraries in:
lib/arm-unknown-linux-gnueabihf/

And clang will now know to look for "arm" instead of "armv8l".
Meaning that we can share libraries between an armv8 and armv7 build
as we did with the previous layout. In addition to handling spelling
differences e.g. "armv8l" with an "l" on some Linux distros.

compiler-rt will autodetect that the "armhf" and/or "arm" architecture
can be built. We then replace the given triple's architecture with that.
Then if the triple's float ABI doesn't match, we change that. That new
triple is then used as the folder name.

If you select to build only the given triple, with COMPILER_RT_DEFAULT_TARGET_ONLY,
compiler-rt will not autodetect the architecture and for that I assume you
know what you're doing. In that case the library path will use the unomdified triple.

From what I can tell, this is how most large builds e.g Android and
Arm's Embedded Toolchain for llvm do things. I assume that big endian "armeb"
builds would end up doing this too.

Bare metal builds will not be using per target runtime dirs so they
remain as they were.

Depends on D139536

Diff Detail

Event Timeline

DavidSpickett created this revision.Dec 14 2022, 4:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 14 2022, 4:20 AM
DavidSpickett requested review of this revision.Dec 14 2022, 4:20 AM
Herald added projects: Restricted Project, Restricted Project, Restricted Project. · View Herald TranscriptDec 14 2022, 4:20 AM
Herald added subscribers: llvm-commits, Restricted Project, cfe-commits, MaskRay. · View Herald Transcript
DavidSpickett added reviewers: MaskRay, phosek.

The first attempt at this was https://reviews.llvm.org/D110142.

The key difference is that...

It also seems like armhf-unknown-linux-gnueabihf duplicates the hf bit (there's both armhf and gnueabihf) which seems unnecessary.

I have solved this. The folder name is no longer a redundant (and, I found out, invalid) triple.

I haven't tested this on a BSD myself. I don't see a major reason it wouldn't work but if you think it's going to have issues I can do that testing and/or restrict this change to Linux only initially.

Thanks for doing this!

clang/lib/Driver/ToolChain.cpp
581

The comments can be combined. First state what this block does, then state that armeb is left out for a reason.

An example may be more descriptive than some words. Give an example of getTriple() and Arch values?

Expand the comment and show an example of changed triples.

DavidSpickett marked an inline comment as done.Dec 15 2022, 3:23 AM
MaskRay accepted this revision.Dec 21 2022, 8:26 PM

Thanks!

This revision is now accepted and ready to land.Dec 21 2022, 8:26 PM

I will wait until after the 16 branch happens to land this. The release build already has some issues and I won't have time to do the fixups in the next few weeks.

phosek accepted this revision.Jan 30 2023, 10:39 PM

LGTM

Remove the Armhf comment, rebase.

This revision was landed with ongoing or failed builds.Jan 31 2023, 1:50 AM
This revision was automatically updated to reflect the committed changes.