When using Clang as a compiler, use Clang to normalize the triple that's
used to construct path for runtime library build and install paths. This
ensures that paths are consistent and avoids the issue where the build
uses a different triple spelling.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
runtimes/CMakeLists.txt | ||
---|---|---|
168 | I think there is one downside to this: the normalize function will not, in fact, normalize alternative spellings for equivalent architectures (and likely other components, I haven't checked that): + clang -print-target-triple -target amd64-unknown-linux-musl amd64-unknown-linux-musl + clang -print-target-triple -target x86_64-unknown-linux-musl x86_64-unknown-linux-musl So the issue where the distribution build can install runtimes in paths that won't be found by the driver still remains (https://github.com/llvm/llvm-project/issues/57781). One way to fix this could be adding a new switch that does a more opinionated normalization (for example, always picks x86_64 in the above). Sort of a reverse for Triple::parseArch etc. where it always returns one certain spelling when there are multiple common alternatives. Alternatively, normalize could be changed to do this, but that might subtle breaking consequences for users which are hard to foresee. |
runtimes/CMakeLists.txt | ||
---|---|---|
168 | I think this is an orthogonal issue to the one that this change is trying to address. Clang currently uses normalized triples to for its include directories (libc++ headers) and runtime libraries. This change ensures that the triple spelling used by CMake and Clang matches, but it doesn't change the normalization logic. From Clang's perspective, amd64-unknown-linux-musl and x86_64-unknown-linux-musl are two different triples and so it'd use different search directories. We could consider changing the normalization rules to normalize these to the same triple, but that should be done separately (and would likely require further discussion to understand the potential consequences of such a change). |
runtimes/CMakeLists.txt | ||
---|---|---|
168 | I don't mean to raise this as a potential blocker and this is certainly somewhat orthogonal. However, I think this not true:
amd64 and x86_64 are very explictly parsed as the same: https://github.com/llvm/llvm-project/blob/6dc85bd3fde7df2999fda07e9e9f2e83d52c6125/llvm/lib/TargetParser/Triple.cpp#L454 I'm not sure if it's a good idea to change the current normalization logic, hence my suggestion for a new flag. But this is probably a discussion for discourse/discord. |
@tamas' suggestion would be a good change to make IMO, but I think it's outside the scope of this patch, and the patch as-is improves the status quo, so LGTM.
Is there any way to share the normalization logic between the two locations, or does compiler-rt's CMake logic still need to be standalone?
compiler-rt/lib/builtins/CMakeLists.txt | ||
---|---|---|
39 | Maybe something slightly more wordy like NORMALIZE_TARGET_TRIPLE_COMMAND would be a clearer name? |
Ping @ldionne, would you be able to take a look at this soon (or are you okay waiving the libc++ blocking requirement for it)? This is really useful for Android armv7, where the triple is traditionally spelled armv7-none-linux-androideabi but normalized to arvm7-none-linux-android, and this patch would resolve that discrepancy.
This patch looks reasonable. The target triple example can be added into "and avoids the issue where the build uses a different triple spelling." @phosek
I think we should land this. Clang has grown workarounds in the meantime, e.g. https://github.com/llvm/llvm-project/blob/4001ae175cbe351d496a6cd5481a554b346f706d/clang/lib/Driver/ToolChain.cpp#L690-L709, and I think this is much cleaner.
SGTM this was previously blocked on other changes, but those all landed so I can go ahead, rebase and land it today.
runtimes/CMakeLists.txt | ||
---|---|---|
167 | Is there any reason why you're carving out Apple here? Is it because -print-target-triple doesn't work properly on that platform (I think this rings a bell). Anyway, this is non-blocking. |
runtimes/CMakeLists.txt | ||
---|---|---|
167 | I think it's cos LLVM_PER_TARGET_RUNTIME_DIR is not supported for Apple platforms in general. I see a bunch of similar conditionals in other parts of compiler-rt. |
Maybe something slightly more wordy like NORMALIZE_TARGET_TRIPLE_COMMAND would be a clearer name?