failed AVER: (EQ (SB-C::IR2-LVAR-KIND SB-C::2FIRST) :UNKNOWN)

[Stas Boukarev]

(defun test (x)
  (multiple-value-prog1 (bar 10)
    (let ((y (list x)))
      (declare (dynamic-extent y))
      (bar y)
      (if x
          (return-from test)))))

=>
failed AVER: (EQ (SB-C::IR2-LVAR-KIND SB-C::2FIRST) :UNKNOWN)

this is similar to https://bugs.launchpad.net/sbcl/+bug/533930

[Alastair Bridgewater (alastair-bridgewater)]

The surface effect here is that (%NIP-VALUES IR2-CONVERT) is declining (quite properly) to move a DX LVAR. Stack analysis inserted the %NIP-VALUES because the ENTRY LVAR for BLOCK TEST was set up as a UV LVAR by M-V-PROG1, and then overwritten by a NIL in RETURN-FROM TEST while still in the scope of the DX allocation of Y.

How did this situation arise? We start with MAYBE-DELETE-EXIT, which determines that the EXIT node for the RETURN-FROM and the ENTRY node for BLOCK TEST have the same home lambda, and thus it is a local exit and can be deleted. MAYBE-DELETE-EXIT replaces the EXIT node with a "vestigial exit" CAST node in a new block, so as to not collapse the LVARs for the EXIT value and the LVAR for the ENTRY (which was known to cause interestingly random issues with unknown-value LVARs and non-local exit, prompting some of the last round of stack analysis improvements). IR1-OPTIMIZE-CAST then turns around and decides, based in part on the result of MAY-DELETE-VESTIGIAL-EXIT, that the CAST node may be deleted and the value LVAR replaced with the ENTRY LVAR. This last step is what causes the UV LVAR to be overwritten while there is a DX LVAR "on top" of it, which stack analysis decides to treat with a %NIP-VALUES.

Conclusion: MAY-DELETE-VESTIGIAL-EXIT should refuse permission to delete a vestigial exit that crosses a DX allocation extent.