Avoid invalid exact casts in TypeRefining#7529
Merged
Conversation
We previously allowed trivial exact casts (i.e. those where the input and target types are the same) to validate even without custom descriptors enabled to ensure that finalization always produces valid casts. But validation can also produce casts where the cast target is a non-nullable exact reference and the input type is a nullable exact reference to the same heap type. Update validation to allow these casts. This is safe because erasing the exactness of the input and cast types does not change the results of these casts. They succeed iff the input is a non-null value.
Do not merge types that differ in exactness.
RemoveUnusedBrs can introduce new casts when optimizing out br_on_cast and br_on_cast_fail instructions. This happens when the pass finds a more precise type for the fallthrough value reaching the casting branch, allowing it to improve the cast target type. When the branch is subsequently optimized out, this precise type information is recovered with an inserted cast. Update the pass to avoid creating invalid casts to exact types when custom descriptors is not enabled.
These features were previously missed when reading target features sections.
There are several places in the code where we need to make a type inexact only if custom descriptors is disabled. Add a helper to slightly simplify those places.
TypeRefining (both the normal and GUFA variants) is able to infer that a field can be more precise than is immediately apparent from the type of an expression set to that field. In these cases, the pass inserts a cast to recover the more precise type information. When custom descriptors are not enabled, casts to exact types invalid, so avoid introducing new exactness that might need such invalid casts in that case.
kripken
reviewed
Apr 18, 2025
| ;; NO_CD-NEXT: ) | ||
| (func $struct.new (param $inexact (ref null $foo)) (param $exact (ref (exact $foo))) (result anyref) | ||
| (struct.new $bar | ||
| (try (result (ref null $foo)) |
Member
Author
There was a problem hiding this comment.
This is the pattern used in both the explanatory comments and the tests for non-GUFA type refining where casts might be inserted. I don't know if there are any simpler patterns that would lead non-GUFA type refining to insert casts.
Member
There was a problem hiding this comment.
Oh, non-GUFA... yeah, it's harder to get things to happen there. Following the existing pattern sgtm.
kripken
approved these changes
Apr 18, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TypeRefining (both the normal and GUFA variants) is able to infer that a
field can be more precise than is immediately apparent from the type of
an expression set to that field. In these cases, the pass inserts a cast
to recover the more precise type information. When custom descriptors
are not enabled, casts to exact types invalid, so avoid introducing new
exactness that might need such invalid casts in that case.