Add LLVM 19.1.x support for LDC

[liushuyu]

This pull request adds LLVM 19.1.x support for LDC. It is based on previous work by @kinke and @thewilsonator in #4763 and #4735.

Some CI setup is required because it needs 19.1.3 binaries in the forked LLVM repository.

[kinke]

Cheers! I'm preparing the LLVM fork based on v19.1.3.

[kinke]

Okay not looking bad, just lit-test failures to look into, most apparently intrinsic-related too.

[liushuyu]

Done; now all tests passed on CI systems. I also "accidentally" fixed a D-Compute regression introduced in the LLVM 18 port.

[kinke]

Awesome! - I've released https://github.com/ldc-developers/llvm-project/releases/tag/ldc-v19.1.3, so we can switch back to v19.1.3 in the YAMLs.

[liushuyu]

Awesome! - I've released https://github.com/ldc-developers/llvm-project/releases/tag/ldc-v19.1.3, so we can switch back to v19.1.3 in the YAMLs.

Done. I have edited your commit to exclude the commit hash changes.

[liushuyu]

Done. CI passed again.

[liushuyu]

Oh, I think I accidentally shadowed #4726

[kinke]

@thewilsonator: Please take a look.

[liushuyu]

xcode-select: error: invalid developer directory '/Applications/Xcode_16.app

I don't know why the macOS ARM64 CI runner had a problem. According to https://github.com/actions/runner-images/blob/main/images/macos/macos-14-arm64-Readme.md, the CI runner image did not change. Maybe it is a temporary failure that can be fixed by a retry.

[kinke]

Yeah don't worry about that apparent GHA hickup. And note that I can take care of the remaining nits, I'll add a changelog entry anyway. Just waiting for @thewilsonator to confirm the SPIRV stuff. - Thanks!

[liushuyu]

Yeah don't worry about that apparent GHA hickup. And note that I can take care of the remaining nits,

I will need to rebase the pull request against the latest master branch anyways, I will just address those.

I'll add a changelog entry anyway. Just waiting for @thewilsonator to confirm the SPIRV stuff. - Thanks!

For the context, the new data layout string comes from: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L248-L276

[kinke]

For the context, the new data layout string comes from: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L248-L276

Ah thx. I see there are similar strings for SPIRV targets a bit below: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L321-L367. Those have an extra n8:16:32:64- before the G1 suffix.

[liushuyu]

For the context, the new data layout string comes from: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L248-L276

Ah thx. I see there are similar strings for SPIRV targets a bit below: https://github.com/llvm/llvm-project/blob/85eec89600085a054650585d3a3287a6e0a93a50/clang/lib/Basic/Targets/SPIR.h#L321-L367. Those have an extra n8:16:32:64- before the G1 suffix.

I have tested both data layouts; the one with the n8:16:32:64- part will make LDC explode due to "mismatching data layout." I believe Clang have atomics enabled inside their configurations, while LDC doesn't. Correction: nxx part should mean the target has native registers for the sizes specified after the n character. I guess it's a format issue?