================
@@ -766,9 +766,19 @@ ToolChain::getTargetSubDirPath(StringRef BaseDir) const {
return {};
};
- if (auto Path = getPathForTriple(getTriple()))
+ llvm::Triple Triple = getTriple();
+
+ // Try triple as is.
+ if (auto Path = getPathForTriple(Triple))
return *Path;
+ // Match transformations in CompilerRTUtils.cmake:get_compiler_rt_target.
----------------
rorth wrote:
And this is where I think you're fundamentally wrong.
Let me explain, first from a user perspective.
- As long as runtime libs aren't involved, you can use any equivalent form of
the triple, both with `x86_64` and `amd64` just as you see fit, and get
identical results. It doesn't matter here if the triple was determined
automatically by `config.guess` at LLVM build time (as is the case for
`sparc64-unknown-linux-gnu`), specified by the user with `-DLLVM_HOST_TRIPLE`,
or given at compile time with `-target`.
- Even when runtime libs come into play, things still work with both/all forms
when the old/classic/`projects` layout is used.
- Only when users are unlucky enough (either because it's the build time
default on certain OSes or they selected it explicitly) to use the
new/`runtimes` layout, the link fails because the runtime libs aren't found
with such alternative triples. Note that the user has never been given any
indication (warning or error) that there's a problem with that triple, just a
link error. This strongly suggests that `clang` is confused in not being able
to find it's own runtime libs. That's a bug in `cllang`, clear as can be.
Those alternative forms have worked for years if not decades without any
issues, and now they stop only in very specific circumstances. As far as I
know, there's never been any indication that/why some forms of triples are
better than others.
For comparison's sake, see what GCC (or the GNU toolchain in general) do
instead. While they don't take triples at runtime, the configure time handling
gives a good indication how this can be done without all those problems:
While users can easily use alternative forms of triples, GCC uses the
`AC_CANONICAL_TARGET`/`ACX_CANONICAL_TARGET` autoconf macros and only uses the
resulting canonicalized triples internally, e.g. when matching in configure
scripts. Only in user-facing cases (like `gcc -v` output) are the pretty
(user-specified) forms used at all.
I think this is what LLVM should do, too: canonicalize triples at some point
and stick to those canonical forms. The current duplication of (inconsistent)
canonicalizions in `getTargetSubDirPath` and `get_compiler_rt_target` needs to
go. IMO there should be something like `clang -print-canonical-target` or some
such, emitting `clang`'s idea of the canonical form, and `compiler-rt` should
just use that rather than second-guessing `clang` (or vice versa).
This patch is nothing more than a baby step in this direction, removing just
one inconsistency we have today.
https://github.com/llvm/llvm-project/pull/100091
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
