GitHub Actions: Extend PGO to C++ parts of LDC

[kinke]

[on top of #3980]

[kinke]

• Doesn't work on macOS yet, because it's not using a host clang with the same LLVM version.
• Loads of hash mismatches on both Windows and Linux. The main difference between instrumented and PGO'd build is that the former does not use LTO at the moment. This wasn't an issue for the frontend, but that's compiled to a single object file.

[kinke]

Loads of hash mismatches on both Windows and Linux.

Using LTO for the instrumented binary too hasn't gotten rid of those, although the relevant CMake flags should be identical for both instrumented and PGO'd builds now. Perhaps due to vanilla clang 14.0.0 vs. LDC-LLVM v14.0.3?!

[kinke]

Ah, so -fprofile-instr-* != -fprofile-* for clang either - it works now on Linux. On Windows, clang-cl supports -fprofile-generate, but not -fprofile-use (edit: llvm/llvm-project#55564)...

[JohanEngelen]

Ah, so -fprofile-instr-* != -fprofile-* for clang either

Sorry for not being able to help you with the issues. But yes, I did not reinvent anything new, the LDC commandline options are meant to do exactly the thing that clang does.

[kinke]

There are some WTF moments here. So first of all, using vanilla clang 14 as C(++) compiler for the macOS jobs worked fine, even for arm64 cross-compilation. I was expecting trouble with the Xcode SDK, but the only problem was that it's somehow using llvm-ranlib when specifying that clang, which supports no cmdline switches at all and required disabling a (in that case superfluous) CMake workaround. So macOS is basically fine too.

For Windows, instrumentation works fine, but the C++ parts don't actually make use of the profile later on, due to the filed clang-cl oversight. The unsupported cmdline switch is only a warning, not an error, so it'll automatically work as soon as clang-cl supports it.

So everything was looking pretty great, until I tried a CI run without assertions. Windows is still fine, but on Linux and macOS x86_64, there are now lots of hash mismatches, apparently just for the D parts.

[kinke]

Okay, that's sorted now too; those hash mismatches originated from the D parts of the ldc2-unittest executable, which don't use the PGO profiles anymore now.

[kinke]

For some Symmetry code and a Linux debug build, I'm seeing some ~1% reduction in compile times over frontend-PGO only.