Do not let GUFA refine casts to exact when invalid#7530
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.
We already prevented GUFA from introduce new exact casts when custom descriptors is not enabled, but now prevent it from refining existing casts to be exact as well.
kripken
approved these changes
Apr 18, 2025
| ;; We can only refine this cast target to be exact if custom descriptors are | ||
| ;; allowed. | ||
| (ref.cast (ref $foo) | ||
| (global.get $g) |
Member
There was a problem hiding this comment.
Do we need these globals? GUFA can infer exactness itself, it doesn't need the not-yet-existing code for struct.new that you mentioned elsewhere. Unless we don't have the GUFA code to turn GUFA exact into Type exact?
Member
Author
There was a problem hiding this comment.
Right, GUFA doesn't know that an exact reference turns into a depth 1 trivial cone and it doesn't know that a trivial cone can be materialized as an exact reference.
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.
We already prevented GUFA from introduce new exact casts when custom
descriptors is not enabled, but now prevent it from refining existing
casts to be exact as well.