Drop null casts?

[rossberg]

With the latest generalisations to casts in the GC proposal, the instructions ref.as_non_null, br_on_null, and br_on_non_null from this proposal are actually (more or less) subsumed:

(ref.as_non_null) == (ref.cast <ht>)
(br_on_non_null $l) == (br_on_cast_fail $l null bot<ht>) (drop)
(br_on_null $l) ~~ (br_on_cast $l' null bot<ht>)

where <ht> is the heap type of the respective operand, and bot<ht> the bottom type of the respective hierarchy. In the case of br_on_null, however, the label $l needs to have a different type ([(ref null bot<ht>)] instead of []).

Given this, we could remove these instructions without much loss.

[conrad-watt]

Also, if there's discomfort with removing them for code size reasons, could we at least fiddle with their passthrough behaviour so that they are precisely specialisations of the new instructions?

[titzer]

I would prefer to keep these instructions, not only for code size reasons (they are extremely common), but, particularly in the cast of the casts, they go against what @rossberg was arguing for, in that every instruction maps to a straightforward, predictable sequence of machine code. In this case, it would be overloading the casting mechanism to get a single-world nullcheck.

[rossberg]

@titzer, since we have pretty much entirely dropped that goal for casts and gone the opposite way, that particular argument seems strangely inconsistent to me at this point. ;)

FWIW, ref.as_non_null probably was the only common one in my compilers, but still far from hot. The substitute would only be one byte longer in most cases, which is unlikely to make a significant difference in code size.

[titzer]

@rossberg AFAIR, we just decided to add a whole new set of cast opcodes specifically for the abstract types.