-
-
Notifications
You must be signed in to change notification settings - Fork 667
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
feat: add an alwaysInline builtin #2895
base: main
Are you sure you want to change the base?
Conversation
This builtin operates similar to unchecked, by setting a new FlowFlag that is checked in makeCallDirect in the area where the @inline decorator is checked, thereby achieving the same functionality as it.
@JairusSW let me know if anything else is desired for this builtin |
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.
what is the difference between inline and this builtin?
@HerrCai0907 this gives you fine-grained control over when a function is inlined (by specifying it in the relevant call sites, instead of in the definition). @JairusSW has an example as to how this would be useful in as-json. |
@CountBleck would it be possible to just rename it to |
I originally intended to name it |
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 for implement part.
But I have some concern about design. I think we should avoid to pollute global scope. load / store / call_indirect can be mapped to low level wasm instruction directly so we keep them in global scope. But for alwaysInline
and unchecked
, I think we should place them in a special namespace or start with some special prefix.
For C++, std library used compiler-implemented function will start with __
. some builtin function will start with __builtin
. I wonder should we also do something like this?
e.g.
use this like
builtin_opt.unchecked(....)
builtin_opt.alwaysInline(....);
Sounds like a good idea, but I'm hesitant to rename/move |
At least we can start from |
How about to use |
I'll do that. What do you think about a namespace for |
Changes proposed in this pull request:
⯈ Add an
alwaysInline
builtin that inlines any inner function calls