Handle functions that use only arguments.length better
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox125 | --- | fixed |
People
(Reporter: jandem, Assigned: mgaudet)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sp3])
Attachments
(4 files)
I took a quick look at the remaining arguments object allocations in Speedometer after bug 1825014.
A little surprising, almost half of them are for react-stockcharts. It has various small functions that look like this:
d.domain = function(e){
return arguments.length?(a=i.call(e,se),f()):a.slice()
}
d.interpolate = function(e){
return arguments.length?(s=e,f()):s
}
d.range = function(e){
return arguments.length?(l=u.call(e),f()):l.slice()
}
l.x = function(t){
return arguments.length?(e="function"===typeof t?t:o(+t),l):e
}
Bug 1825014 added JSOp::ArgumentsLength for ArgumentsLength() in self-hosted code. I wonder if we could emit the same bytecode op for functions that use only arguments.length and have no other uses of arguments.
This only affects the interpreter and Baseline tiers, but because there are a bunch of functions in react-stockcharts like this, it adds up.
Updated•3 years ago
|
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
Writing down some notes as I look into this:
- Currently we work entirely on the binary assumption: Either we use arguments or we don't. Unfortunately, the arguments binding is weird.
- To do this, we'll need to add a new flag to handle the case where the arguments binding exists, but the only use of it is in
arguments.length. - We may be able to do this in simple cases, but anything requiring flow analysis will have to default to the old pattern; probably the new flag is something along the lines of
SawNonLengthUseOfArguments. - The good news is that we disambiguate argument nodes in the syntax parser, which makes this feasible to do in syntax parsing.
| Assignee | ||
Comment 2•2 years ago
|
||
(Am gently poking this, but don't expect anything soon, and if anyone wants to steal feel free; current patch is only some scaffolding)
| Assignee | ||
Comment 3•2 years ago
|
||
Used later in the stack to disambiguate between use in scope and capture.
Updated•2 years ago
|
| Assignee | ||
Comment 4•2 years ago
|
||
This was validated by doing a parallel implementation intially and making
sure that the two implementations both declared and indicated used in
the exact same circumstances.
| Assignee | ||
Comment 5•2 years ago
|
||
By adding a separate parse node for arguments.length we will be able to
do bytecode generation differently in some circumstances.
| Assignee | ||
Comment 6•2 years ago
|
||
Comment 8•2 years ago
|
||
Backed out 4 changesets (bug 1825722) for causing bc failures at browser_parsable_script.js
Backout: https://hg.mozilla.org/integration/autoland/rev/2cb963dfbca603e5a675bd9b47cd6e993d7044fa
Failure log: https://treeherder.mozilla.org/logviewer?job_id=449148863&repo=autoland&lineNumber=3486
| Assignee | ||
Comment 9•2 years ago
|
||
facepalm Ah yes. Reflect.parse, which I totally forgot about in my joy of getting this functional!
Comment 10•2 years ago
|
||
Comment 11•2 years ago
|
||
Backed out for causing reftest failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/73af30b099fcf9eb7049251e60bcd3de1ac30a44
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
Comment 14•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/e2dbfdc41394
https://hg.mozilla.org/mozilla-central/rev/10b96cddce62
https://hg.mozilla.org/mozilla-central/rev/847a07f3f127
https://hg.mozilla.org/mozilla-central/rev/086ffc46a18e
| Assignee | ||
Updated•2 years ago
|
Description
•