Bump LDC-LLVM to v21.1.7

[kinke]

[calvin2021y]

Any updates on this #4943? We'd love to get it merged with llvm21 if possible!

[kinke]

Any help in #4943 would be appreciated, in case you e.g. have the ability to test it locally - it would e.g. be good to know whether the test failures are legit, or specific to the GHA runner container environment. Troubleshooting via CI is a huge PITA and incredibly time-consuming with the poor feedback times.

[calvin2021y]

I am not sure how to test it local, I try to build get this error on x86:

Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.start.p0(ptr immarg %5) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.start.p0(ptr immarg %6) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.end.p0(ptr immarg %6) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.end.p0(ptr immarg %5) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.start.p0(ptr immarg %5) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.start.p0(ptr immarg %6) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.end.p0(ptr immarg %6) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.end.p0(ptr immarg %5) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.start.p0(ptr immarg %7) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.end.p0(ptr immarg %7) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.start.p0(ptr immarg %10) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.start.p0(ptr immarg %11) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.end.p0(ptr immarg %11) #2
Incorrect number of arguments passed to called function!
  call void @llvm.lifetime.end.p0(ptr immarg %10) #2
LLVM ERROR: Broken module found, compilation aborted!
Aborted (core dumped)
ninja: subcommands failed

will update aarch64 late.

[thewilsonator]

I am not sure how to test it local, I try to build get this error on x86: ... will update aarch64 late.

See https://github.com/ldc-developers/ldc/pull/4990/commits/ffed80310b07931a5e91d4d1d4e46ba61019a874 note that phobos will still fail to build as with https://github.com/ldc-developers/ldc/pull/4979

[kinke]

@calvin2021y: I meant testing on Alpine AArch64, using a supported LLVM version < 21.

[kinke]

Oof, pretty discouraging first test results for CI.

[calvin2021y]

@calvin2021y: I meant testing on Alpine AArch64, using a supported LLVM version < 21.

Thanks for the tips. I try build the tests on aarch64. find a problem:

use '-DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++ -fuse-ld=lld"` will blocked by:

ldmd2 -linkonce-templates -O -defaultlib=phobos2-ldc,druntime-ldc -wi -O -inline -release -of/opt/projects/ldc/bin/timetrace2txt /opt/projects/ldc/obj/timetrace2txt.o -gcc=/usr/lib/llvm20/bin/clang++ "-Xcc=-static-libstdc++ -fuse-ld=lld" -Xcc=-static -Xcc=-fuse-ld=lld

clang++: error: unknown argument: '-static-libstdc++ -fuse-ld=lld'

'-static-libstdc++ -fuse-ld=lld' should be 2 arguments here.

[the-horo]

@calvin2021y: I meant testing on Alpine AArch64, using a supported LLVM version < 21.

Thanks for the tips. I try build the tests on aarch64. find a problem:

use '-DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++ -fuse-ld=lld"` will blocked by:

ldmd2 -linkonce-templates -O -defaultlib=phobos2-ldc,druntime-ldc -wi -O -inline -release -of/opt/projects/ldc/bin/timetrace2txt /opt/projects/ldc/obj/timetrace2txt.o -gcc=/usr/lib/llvm20/bin/clang++ "-Xcc=-static-libstdc++ -fuse-ld=lld" -Xcc=-static -Xcc=-fuse-ld=lld

clang++: error: unknown argument: '-static-libstdc++ -fuse-ld=lld'

'-static-libstdc++ -fuse-ld=lld' should be 2 arguments here.

Use -DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++;-fuse-ld=lld". Separate the arguments by ;, not by .

[thewilsonator]

fix.diff.txt

This fixes a few Lit test suite failures

[thewilsonator]

For the record https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGDecl.cpp#L1375 has just Addr now no Size.

[kinke]

For the record https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CGDecl.cpp#L1375 has just Addr now no Size.

Yep, but that's LLVM 22, not 21: https://github.com/llvm/llvm-project/commit/c23b4fbdbb70f04e637b488416d8e42449bfa1fb

[kinke]

Okay, looking much better now; the problem was a GC2Stack regression introduced in a recent prepare-for-LLVM-21 PR. - Basically just a std.json unittest regression remaining (with enabled optimizations only), and some linking issue for ldc-profgen on macOS arm64 (with clang 21 at least).

[kinke]

The std.json regression smells like an LLVM regression unfortunately. This asserts with -O:

import std.json;

void main()
{
    JSONValue j;
    j["rating"] = 42;
}

std.json.JSONException@std/json.d(337): JSONValue is not an object
----------------
[…]
std/json.d:337 [0x5cbb34d83b51]
std/json.d:850 [0x5cbb34d68b47]
test.d:6 [0x5cbb34d68a68]

The problem seems to be that the type == JSONType.object check becomes an assumed true for some reason, while the default-initialized JSONValue is of type JSONType.null_.

Unoptimized surrounding IR:

 else:                                             ; preds = %andandend
  store ptr null, ptr %aa, align 8
  %56 = call signext i8 @_D3std4json9JSONValue4typeMxFNaNbNdNiNfZEQBnQBm8JSONType(ptr nonnull %.this_arg) #3 ; [#uses = 1]
  %57 = sext i8 %56 to i32                        ; [#uses = 1]
  %58 = icmp eq i32 %57, 6                        ; [#uses = 1]
  br i1 %58, label %if15, label %endif16

if15:                                             ; preds = %else
  %59 = call ptr @_D3std4json9JSONValue11objectNoRefMNgFNaNdNeZNgHAyaSQByQBxQBv(ptr nonnull %.this_arg) #3 ; [#uses = 1]
  store ptr %59, ptr %aa, align 8
  br label %endif16

endif16:                                          ; preds = %if15, %else

Optimized:

else:                                             ; preds = %_D3std9exception__T7enforceHTCQBc4json13JSONExceptionZ__TQBmTbZQBsFNaNfbLAxaAyamZb.exit, %andand
  store ptr null, ptr %aa, align 8
  %26 = tail call signext i8 @_D3std4json9JSONValue4typeMxFNaNbNdNiNfZEQBnQBm8JSONType(ptr nonnull %.this_arg) #3 ; [#uses = 1]
  %27 = icmp eq i8 %26, 6                         ; [#uses = 1]
  tail call void @llvm.assume(i1 %27)      ; <<<<< WTF
  %28 = tail call ptr @_D3std4json9JSONValue11objectNoRefMNgFNaNdNeZNgHAyaSQByQBxQBv(ptr nonnull %.this_arg) #3 ; [#uses = 3]
  store ptr %28, ptr %aa, align 8

godbolt with LLVM 20 keeps the icmp+branch:

else:
  store ptr null, ptr %aa, align 8, !dbg !68
  %24 = tail call signext i8 @const pure nothrow @property @nogc @safe std.json.JSONType std.json.JSONValue.type()(ptr nonnull %.this_arg) #3, !dbg !71
  %25 = icmp eq i8 %24, 6, !dbg !71
  br i1 %25, label %if11, label %endif12

if11:
  %26 = tail call ptr @inout pure @property @trusted inout(std.json.JSONValue[immutable(char)[]]) std.json.JSONValue.objectNoRef()(ptr nonnull %.this_arg) #3, !dbg !73
  store ptr %26, ptr %aa, align 8, !dbg !73
  br label %endif12

endif12:

[thewilsonator]

FWIW, this regression seems to have been fixed in LLVM22.

[kinke]

Hmm, std.json now passes after #5029, using the same LLVM v21.1.7 as before. std.json itself wasn't touched at all. So the LLVM bug might still be lingering in v21.1.8 after all... :/