When accessing the data pointer for an array, first decay it to a Derived Pointer

[gbaraldi]

Fixes #54266, I've not yet minimized something to put into a test but in any case we can add the large test since it executes quite quickly.

This also enables IR verification with Strong=true when building with assertions, this would've caught this bug much earlier.

[Keno]

A pointer GEP in addrspace 10 is basically never legal (because each object is a separate allocation and there's only one addrspace 10 pointer that's valid in that allocation). Can we add this to the verifier? Then adding a test for this will also become easy.

[Keno]

Actually, we already have it

julia/src/llvm-gc-invariant-verifier.cpp

Line 139 in f712512

void GCInvariantVerifier::visitGetElementPtrInst(GetElementPtrInst &GEP) {

:

    /* We're actually ok with GEPs here, as long as they don't feed into any
       uses. Upstream is currently still debating whether CAST(GEP) == GEP(CAST).
       In the frontend, we always perform CAST(GEP), so while we can enforce
       this invariant when we run directly after the frontend (Strong == 1),
       the optimizer will introduce the other form. Thus, we need to allow it
       while upstream hasn't decided whether the optimizer is allowed to
       introduce these.
       */
    if (Strong) {
        Check(AS != AddressSpace::Tracked,
             "GC tracked values may not appear in GEP expressions."
             " You may have to decay the value first", &GEP);
    }

But clearly it's not triggering in this example, so we may need to enhance it.

[gbaraldi]

@Keno the issue is that the check is behind the Strong flag, you have a comment there as to why we may disable this, do you know if we can just remove that check?
Making the check unconditional does find this.

[Keno]

As the comment indicates, the Strong version of this should run on the IR that we output from the frontend, which is supposed to catch this issue.

[Keno]

I don't believe LLVM has decided the pointercast vs gep issue.

[gbaraldi]

So we should run the verifier twice then? Once before optimization and once after with Strong off?

[Keno]

Yes, that's how it's designed (in debug mode only of course). It's possible we lost one of the passes.

[gbaraldi]

I'm tempted to move this check to run when assertions are on instead of just debug. Debug is not part of CI nor PkgEval and that pass isn't particularly expensive, it should be O(N) with a small constant

[Keno]

That's fine.