[embedded] Fix miscompile in IRGen in offset computation of Builtin.destroyArray

[kubamracek]

In Embedded Swift, IRGen emits the loop to destroy values in the array directly. Turns out that the GEP we use to index into the individual elements of the array's storage is using the value's size and not the stride in some cases, concretely in cases where the type is an enum with payloads. E.g. this

struct S: ~Copyable {
    deinit {
        print("S deinitialized!")
    }
}

enum Node {
    case inner(S)
    case leaf(Int)
}

ends up being represented as this type in LLVM IR:

%T1a4NodeO = type <{ [8 x i8], [1 x i8] }>

...on which GEP will not do the right thing we want (stride). Let's compute the offset directly via ptrtoint, add, inttoptr.

Will add tests, but wanted to check that this is the right approach first.

rdar://126386301

[kubamracek]

@swift-ci please test

[eeckstein]

Out of curiosity: why do we need to do something different in embedded swift for destroyArray? Can't we just use the typeinfo's destroyArray?

[eeckstein]

adding @aschwaighofer as reviewer

[eeckstein]

Don't we have the same problem with the other array builtins, like copyArray?

[aschwaighofer]

lgtm

[kubamracek]

Out of curiosity: why do we need to do something different in embedded swift for destroyArray? Can't we just use the typeinfo's destroyArray?

That would emit a call to a runtime function (swift_arrayDestroy) which needs metadata and witness tables to be able to do the right destroy.

[kubamracek]

It probably deserves a comment/explainer in the source code :)

[kubamracek]

Added comments, applied the fix to the init/take/assign builtins too (@eeckstein you're right we needed it there too), added a testcase.

[kubamracek]

@swift-ci please test

[eeckstein]

thanks! lgtm