[clang] [Driver] Have getTargetSubDirPath better match get_compiler_rt_target (PR #100091)

[Rainer Orth via cfe-commits]

================
@@ -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