Skip to content

Conversation

kripken
Copy link
Member

@kripken kripken commented Feb 20, 2024

This pulls out the subtype-exprs.h parts of #6108

These are NFC in the current codebase, but are fixes for that unlanded PR. I suggest we
land those because they can help other unrelated work even if we never land that PR.

@kripken kripken requested a review from tlively February 20, 2024 18:58
Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice if we could test the new code somehow. Do you have an immediate use in mind?

self()->noteSubtype(seg->type, array.element.type);
}
void visitRefAs(RefAs* curr) {}
void visitRefAs(RefAs* curr) { self()->noteCast(curr->value, curr); }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should only be for ref.as_non_null. The internal/external reference conversions are not casts.

@kripken
Copy link
Member Author

kripken commented Feb 20, 2024

Yes, I will open a PR right after this with a usage of this. The PR will replace the hacks in StringLowering for nulls with new code that uses this to find which nulls we need to fix.

@kripken
Copy link
Member Author

kripken commented Feb 20, 2024

I forgot to say, and as a result this will be tested in the next PR.

Any other thoughts on this one?

Copy link
Member

@tlively tlively left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@kripken kripken merged commit 40a4bd0 into WebAssembly:main Feb 20, 2024
@kripken kripken deleted the subtype.exprs branch February 20, 2024 21:43
kripken added a commit that referenced this pull request Feb 27, 2024
) When we do a local.set of a value into a local then we have both a subtyping constraint - for the value to be valid to put in that local - and also a flow of a value, which can then reach more places. Such flow then interacts with casts in Unsubtyping, since it needs to know what can flow where in order to know how casts force us to keep subtyping relations. That regressed in the not-actually-NFC #6323 in which I added the innocuous lines to add subtyping constraints in ref.eq. It seems fine to require that the arms of a RefEq must be of type eqref, but Unsubtyping then assuming those arms flowed into a location of type eqref... which means casts might force us to not optimize some things. To fix this, differentiate the rare case of non-flowing subtyping constraints, which is basically only RefEq. There are perhaps a few more cases (like i31 operations) but they do not matter in practice for Unsubtyping anyhow; I suggest we land this first to undo the regression and then at our leisure investigate the other instructions.
radekdoulik pushed a commit to dotnet/binaryen that referenced this pull request Jul 12, 2024
This pulls out the subtype-exprs.h parts of WebAssembly#6108 These are NFC in the current codebase, but are fixes for that unlanded PR, and another unrelated PR that will be opened shortly.
radekdoulik pushed a commit to dotnet/binaryen that referenced this pull request Jul 12, 2024
…bAssembly#6344) When we do a local.set of a value into a local then we have both a subtyping constraint - for the value to be valid to put in that local - and also a flow of a value, which can then reach more places. Such flow then interacts with casts in Unsubtyping, since it needs to know what can flow where in order to know how casts force us to keep subtyping relations. That regressed in the not-actually-NFC WebAssembly#6323 in which I added the innocuous lines to add subtyping constraints in ref.eq. It seems fine to require that the arms of a RefEq must be of type eqref, but Unsubtyping then assuming those arms flowed into a location of type eqref... which means casts might force us to not optimize some things. To fix this, differentiate the rare case of non-flowing subtyping constraints, which is basically only RefEq. There are perhaps a few more cases (like i31 operations) but they do not matter in practice for Unsubtyping anyhow; I suggest we land this first to undo the regression and then at our leisure investigate the other instructions.
@gkdn gkdn mentioned this pull request Aug 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants