binaryen icon indicating copy to clipboard operation
binaryen copied to clipboard

Opportunity to further simplify internal cast representation

Open tlively opened this issue 2 years ago • 2 comments

Right now almost all casts are represented as RefCast expressions, but ref.as_non_null is instead represented as a RefAs expression. This is a little awkward because the other two operations represented by RefAs are actually not casts at all, but rather conversions to and from externref. Having casts spread across two expression classes and having both cast and conversion operations represented by RefAs are sources of unnecessary complexity.

We could instead represent ref.as_non_null as a RefCast where the cast target heap type is a subtype of the input heap type. Another way to say this is that we could remove the RefAs representation of ref.as_non_null and instead opportunistically emit ref.as_non_null instead of ref.cast when the types work out.

tlively avatar Jun 07 '23 17:06 tlively

One possible issue is that RefCast means "cast to this type exactly" while RefAsNonNull means "whatever the input type is, cast to the non-nullable version of that." So if the child changes, the meaning of the two differs. Though, given we propagate types in ReFinalize anyhow, this might be moot, but I'm not sure.

kripken avatar Jun 07 '23 17:06 kripken

Since it's always valid to refine a type, it's valid to "optimize" a RefCast to a ref.as_non_null in the binary and text emitters (and of course also in passes like OptimizeInstructions) whenever it would produce a subtype of the type the ref.cast would produce. ReFinalize also already improves RefCast types according to the same principle.

tlively avatar Jun 07 '23 17:06 tlively