-
-
Notifications
You must be signed in to change notification settings - Fork 649
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
fix: direct call optional parameter function in more cases #2676
fix: direct call optional parameter function in more cases #2676
Conversation
24146f1
to
f507219
Compare
f507219
to
81bc6cd
Compare
Note that unary prefix operators can be overloaded, in which case these won't compile to a const. The proposed changes might hence be problematic. |
In this case |
Currently, references are just i32s, though. Imagine, for example somefunc(!"somestring") where (call $String#__not
(i32.const ...)
) that not only checks whether the value is |
we cannot overload operator for literal type. And that is the reason I change the function name. |
Looks like I need to revert the change for |
For reference, here's what the compiler does for unary prefix assemblyscript/src/compiler.ts Lines 9372 to 9405 in 688746a
Note the checks for operator overloads, which might exist on wrapper classes, and that implicit negation is limited to numeric literals, excluding string literals. |
I don't find any overload in current implement of number wrapper class. |
My point is rather that the check becomes too brittle for my taste, as |
unfortunately it cannot inline. (func $assembly/index/_start
i32.const 1
global.set $~argumentsLength
i32.const 3
call $assembly/index/foo@varargs
i32.const 1
global.set $~argumentsLength
i32.const 4
call $assembly/index/foo@varargs
) const t = -1;
export let v1 = 0;
export let v2 = "";
function foo(a: i32, b: i32 = t): void {
v1 = a + b;
v2 = a.toString() + b.toString();
}
export function _start(): void {
foo(3);
foo(4);
} |
True, looks like there it doesn't inline because other things have already been inlined into the stub, then becoming too big to be worth to inline. That's indeed unfortunate. I guess could be mitigated by generating multiple stubs, one per number of arguments, as that'd suppress the br_table while otherwise only moving where things are inlined concretely hmm. |
Perhaps as a compromise for the time being: Let's make |
stub varargs function can be optimized in those cases: