Update LocalSubtyping for exact references #7355
Merged
Conversation
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
Update the finalization of all instructions whose types (or sent types) depend on their operand reference types to handle exact references correctly. Specifically, update `ref.as_non_null`, `br_on_null`, `br_on_non_null`, `br_on_cast`, and `br_on_cast_fail`. Also add TODOs on all instructions that allocate new heap objects to remind us to make their types exact in the future.
When optimizing a cast to an exact reference to a bottom type, OptimizeInstructions previously triggered an assertion that expected the cast type to be inexact. Fix the assertion and surrounding code to be more robust to the presence of exact reference types and add a test.
After calculating the best possible type for a local, LocalSubtyping then checks to see whether the local can be non-nullable based on whether all of its gets are dominated by sets. If it cannot be non-nullable, the new type is adjusted to be nullable. This adjustment did not previously preserve exactness, causing an assertion that the optimization improves the type to fail. Fix the adjustment and add a test.
kripken
reviewed
Mar 10, 2025
| if (cannotBeNonNullable.count(i)) { | ||
| newType = Type(newType.getHeapType(), Nullable); | ||
| newType = | ||
| Type(newType.getHeapType(), Nullable, newType.getExactness()); |
Member
There was a problem hiding this comment.
Perhaps it makes sense to add getAsNullable() or getWithNullability(nullability)? That would shorten such code, and be forward looking for when we add yet more things aside from shareability, nullability, exactness, etc....
Member
There was a problem hiding this comment.
Actually it could be getAs(nullability) which is nice and short.
Member
|
I am ok with leaving such refactoring to later, but the more I think about it, while you are making these changes it would be good to do it, and not be any more work? |
Member
Author
|
Yes, I've had the same thought. I was planning to leave such a refactoring to later, but you're right that it would make sense to update the use sites as I fix bugs incrementally. How about we land the current batch of PRs, and then I'll add the new API and update all these fixed use sites to use it. Subsequent bug fix PRs can then use the new API right away. |
Member
|
Sounds good. |
kripken
approved these changes
Mar 10, 2025
tlively
added a commit
that referenced
this pull request
Mar 26, 2025
We decided that Custom Descriptors should introduce exact heap types rather than exact reference types. Although these new features are very similar, the APIs we need to change for them are completely different. One option would have been to keep the existing exact reference type implementation while additionally implementing exact heap types, but there are not enough free bits in the type implementation to have both at once without increasing the alignment of HeapTypeInfo allocations. Portably increasing the alignment is annoying enough that it's easier to just eagerly remove exact reference types to free up the bit for use with exact heap types. Fully or partially revert the following PRs: - #7371 - #7365 - #7360 - #7357 - #7356 - #7355 - #7354 - #7353 - #7347 - #7342 - #7328 Keep the new `.with(...)` Type APIs and the relevant parts of the type relations gtest that were introduced as part of the reverted work.
tlively
added a commit
that referenced
this pull request
Mar 26, 2025
We decided that Custom Descriptors should introduce exact heap types rather than exact reference types. Although these new features are very similar, the APIs we need to change for them are completely different. One option would have been to keep the existing exact reference type implementation while additionally implementing exact heap types, but there are not enough free bits in the type implementation to have both at once without increasing the alignment of HeapTypeInfo allocations. Portably increasing the alignment is annoying enough that it's easier to just eagerly remove exact reference types to free up the bit for use with exact heap types. Fully or partially revert the following PRs: - #7371 - #7365 - #7360 - #7357 - #7356 - #7355 - #7354 - #7353 - #7347 - #7342 - #7328 Keep the new `.with(...)` Type APIs and the relevant parts of the type relations gtest that were introduced as part of the reverted work.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
After calculating the best possible type for a local, LocalSubtyping
then checks to see whether the local can be non-nullable based on
whether all of its gets are dominated by sets. If it cannot be
non-nullable, the new type is adjusted to be nullable. This adjustment
did not previously preserve exactness, causing an assertion that the
optimization improves the type to fail. Fix the adjustment and add a
test.