Miscompilation with -opaque-pointers=true with LLVM16

[JohanEngelen]

Testcase from druntime rt/lifetime.d line 2686 miscompiles with -opaque-pointers=true -O:

static struct S
{
    S* thisptr;
    ~this() { assert(&this == thisptr); thisptr = null;}  // This assertion is triggered
}

void main() {
    S[] test14126 = new S[2048]; // make sure we allocate at least a PAGE
    foreach (ref s; test14126)
    {
        s.thisptr = &s;
    }
}

(no need to add this testcase when the bug is fixed, because it is already part of the testsuite when opaque pointers are enabled)

[JohanEngelen]

This might be a bug in LLVM16.

Modified the testcase a little:

static struct S
{
    S* thisptr;
    ~this() {
        assert(&this == thisptr);
        thisptr = null;
    }
}

void foo() {
    S[] test14126 = new S[74];
    foreach (ref s; test14126)
    {
        s.thisptr = &s;
    }
    import core.stdc.stdio; printf("%p\n", &test14126[$-1]);
    import core.stdc.stdio; printf("%p\n", test14126[$-1].thisptr);
}

void main() {
    foo();
}

It bugs already in the printfs.

LLVM16 --opaque-pointers=true:
0x104224248
0x104224240 <-- mismatch!

LLVM17 gives correct output
0x10117c008
0x10117c008

I cannot find any fault in our outputted LLVM IR. Looks like a vectorization bug in LLVM16, because the optimized IR does look bad (writes same pointer to test14126[x].thisptr and test14126[x+1].thisptr).

[kinke]

OMG. And the CI-tested LLVM 16 version is our LDC-LLVM, based on v16.0.6, the latest patch for the v16 family. Ouch, so much for the plan to use LLVM 16 + opaque pointers by default in LDC v1.36. :(

[kinke]

FWIW, I've just pushed https://github.com/ldc-developers/llvm-project/tree/ldc-release/17.x (preliminary so far).

[kinke]

Also seen with LLVM v15.0.6 on Linux x86_64: https://github.com/ldc-developers/ldc/actions/runs/9052573385/job/24870398659?pr=4657