Closed fibrechannelscsi closed 7 months ago
Tagging @aschwaighofer
The first testcase is triggering a bug somewhere in LoadableByAddress. It is again workarounded by -disable-large-loadable-types-reg2mem
and therefore likely was introduced in https://github.com/apple/swift/commit/5e2144bdb8a25e594cefcfedb60dd31f17572c9e
The bug is happens on AddressAsignment inside s4main1LV1sAA1HVyFTJrSpSr
while rewriting the following SIL:
%222 = tuple $(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double) (%82, %101, %111, %131, %141, %161, %171, %191, %201) // user: %226
...
%225 = pointer_to_address %224 : $Builtin.RawPointer to [strict] $*(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double) // user: %226
store %222 to %225 : $*(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double) // id: %226
The code is trying to create copy_addr
from:
%1 = alloc_stack $(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (@in_guaranteed P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double) // users: %220, %218, %216, %214, %212, %210, %208, %206, %204
to:
%225 = pointer_to_address %224 : $Builtin.RawPointer to [strict] $*(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double) // user: %226
Before LoadableByAddress the code was fine:
%202 = tuple $(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double,
@callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.Differe
ntiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double) (%80, %99, %109, %1
29, %139, %159, %169, %189, %199) // user: %206
...
%205 = pointer_to_address %204 : $Builtin.RawPointer to [strict] $*(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.Differentiab
leView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.Ta
ngentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guar
anteed (@inout Double) -> Double) // user: %206
store %202 to %205 : $*(predecessor: _AD__$s4main1LV1sAA1HVyF_bb2__Pred__src_0_wrt_0, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector
>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double, @callee_guaranteed (P.TangentVector) -> @owned Array<P.TangentVector>.DifferentiableView, @callee_guaranteed (@inout Double) -> Double) // id: %20
6
Looks like LoadableByAddress create improper tuple type for alloc_stack
above somehow...
Ok, looks like the LargeValueVisitor
does not handle pointer_to_address
instruction properly when it might have a tuple type argument and does not mark it for rewriting. Preparing a fix.
@fibrechannelscsi The second testcase is unrelated and is due to autodiff. I'm factoring it out into a separate issue.
Description
Enclosed are two reproducers that will reach the same assertion failure in the same line of code, however, the stack trace is different for each of them. One stack trace contains the
SILPassManager
, and the other contains both theSILPassManager
andSILCloner
. Further details below.Based on the 2024-03-07a toolchain, the assertion failure is:
Assertion failed: (srcAddr->getType() == destAddr->getType()), function createCopyAddr, file SILBuilder.h, line 1177.
Reproduction
Compile either of the following reproducers in Debug mode using the 2024-03-07a or 2024-03-13a nightly toolchains:
Reproducer 1:
Reproducer 2:
Note that Reproducer 2 is a condensed version of "Crash 4" described here: https://github.com/apple/swift/issues/59429
That is to say, Reproducer 1 is another way of reaching the same assertion failure as Reproducer 2, albeit via a different stack trace.
Expected behavior
The compilation should succeed for Reproducer 1. For Reproducer 2, the compilation should succeed, or the compiler should produce an error message indicating why the compilation cannot succeed.
Environment
Reproducer 1 will fail to compile with the 2024-03-07a or 2024-03-13a nightly toolchains. However, compilation will succeed with the 2023-12-07a toolchain.
Reproducer 2 will fail to compile with all three toolchains listed above. That is, the issue is still open.
Additional information
Here are the stack traces for each issue (from the 2024-03-07a toolchain): Reproducer 1:
Reproducer 2:
Note that, for Reproducer 1, all four
+=
operations are required to reproduce this crash. If one or more of them are commented out, then the compilation will succeed. In addition, commenting out the line containingvar e = 0.0
will also cause the compilation to succeed, even though the variablee
is not used anywhere.