[PATCH] D120654: WoA: Change target triple & try_compile config

Andrzej Warzynski via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 28 06:19:19 PST 2022


awarzynski accepted this revision.
awarzynski added a comment.

Thanks for this patch, @rovka !

This change makes a lot of sense to me. Essentially, it makes the CMake configuration:

- more explicit (by including the vendor), and
- more consistent with LLVM triple definition <https://github.com/llvm/llvm-project/blob/11d144c57642ff9a7f393bc6a4809f75007ff73f/llvm/include/llvm/ADT/Triple.h#L27-L30>, which _always_ includes the vendor:

> ARCHITECTURE-VENDOR-OPERATING_SYSTEM
> or
> ARCHITECTURE-VENDOR-OPERATING_SYSTEM-ENVIRONMENT

Now, there are these confusing failures in Flang, which are most likely related to "effective" triples. Clang allows you to skip the vendor and it probably does that for consistency with GCC (from https://wiki.osdev.org/Target_Triplet):

> (...) since the vendor field is mostly unused, the GNU build system allows you to leave out the vendor field;

However, internally Clang uses so-called "effective" triples, which do contain the vendor (here's a Clang test <https://github.com/llvm/llvm-project/blob/main/clang/test/Driver/print-effective-triple.c> to demonstrate this). As Flang's **compiler driver** is based on `clangDriver` (Clang's driver library), it inherits this logic. In many cases, it doesn't matter whether you use:

  -DLLVM_HOST_TRIPLE=aarch64-windows-msvc

or

  -DLLVM_HOST_TRIPLE=aarch64-pc-windows-msvc

because (note how the vendor is included in the output):

  clang -target aarch64-windows-msvc --print-effective-triple
  aarch64-unknown-windows-msvc19.11.0

The effective triple is what `clangDriver` will use internally. However, the tests that @rovka is referring to are Flang's **frontend driver** unit tests. Neither the frontend driver nor the corresponding unit tests in Flang use `clangDriver`, so `aarch64-windows-msvc` is used verbatim and `windows` is parsed as vendor and `msvc` as OS. And things go "wrong". This is not an issue in Clang, as AFAIK there are no unit tests like this (i.e. most/all code-gen tests are LIT tests that are run via `clang`).

OK, that's a long comment, I hope that it makes sense :) Many thanks to Diana for digging into this with me!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D120654/new/

https://reviews.llvm.org/D120654



More information about the llvm-commits mailing list