-
Notifications
You must be signed in to change notification settings - Fork 825
Make imported functions inexact #7993
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Update the Literal constructors for funcrefs to take Type instead of HeapType to allow them to be given inexact function references types when the referenced function is an import. Use the new capability to give references to imported functions inexact types in GUFA. Add a test where this change fixes a misoptimization as well as tests where this change simply changes the nature of the misoptimization. Future PRs will fix these tests.
The meaning of Global in PossibleContents changes from "an actual wasm Global" to "an immutable global wasm thing, either a Global or a Function." Imported wasm Functions are effectively immutable values in the global scope - not concrete, specifically-known functions - so this is more correct. In particular, two imported Globals (of compatible types) might or might not be the same, and likewise with imported Functions. And that is not the case for defined Functions - they are definitely different. This does not fix the issues related to imported function type handling - #7993 does that - but this refactoring makes it possible to properly optimize imported functions afterward. This does make the PossibleContents object grow from 32 to 40 bytes, which might be why this adds 3-4% overhead to GUFA, but I don't see a good way to avoid that, unfortunately. Keeping our ability to optimize imported functions might be worth that 3-4% (we recently saw a few digits improvement due to properly optimizing imported externs, for example, from #8005).
|
Adding validation that defined (i.e. non-imported) functions must have exact types exposes a bug in the JSPI pass. |
|
After merging main, which includes the GUFA change for imported functions, a fix was required here in GUFA.cpp: We used to only have globals as an exception there, and now must have functions as well (for imported ones). This becomes an issue in this PR as exactness changes make it noticeable, and this affected a new test here. |
Where can I see that? |
|
I found that when I started working on a new PR using this one as the base. Here's the diff to apply: |
|
Basically we should move the exactness type checking from |
|
Done. |
tlively
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once CI and fuzzers are happy
|
good catch @tlively on that missing validation 😄 that caused a lot of things to be missed earlier... |
Defined functions remain exact, but imported ones are inexact.
This is a step along the recent Custom Descriptors spec changes.
RefFunc::finalizeandLiteral::makeFuncvariants get the module, and look upthe type there.
Builder::makeRefFuncvariant gets a Type and applies it. The HeapTypevariant does a lookup on the module (so the Type one is more efficient/applicable
if the IR is not fully built yet).
look up the type of the import; see changelog, this seems the least-annoying way to
update here, avoiding new APIs, and less breakage for users - hopefully none, all our
tests here pass as is).