The MSetFrameArgument case in IonBuilder::jsop_setarg seems to be dead code
Categories
(Core :: JavaScript Engine: JIT, defect, P3)
Tracking
()
People
(Reporter: anba, Assigned: anba)
References
Details
Attachments
(7 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
Updated•7 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Add IonBuilder::jsop_getarg next to the existing IonBuilder::jsop_setarg, so
we have both operations next to each other, which makes it easier to compare
how aliased arguments are handled.
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Drive-by change: GET_ARGNO(pc)
is passed to the function as arg
, so we
don't need to recompute it again within the function.
Depends on D64567
Assignee | ||
Comment 3•5 years ago
|
||
Restructure jsop_setarg()
to make it clearer when we abort Ion compilation.
The MSetFrameArgument
code added in bug 921120 (and later disabled in bug 957475),
was written before bug 995336, so it did handle a case which can no longer happen,
namely JSOp::SetArg
bytecode operations on lazy arguments. If we want to support
the use case from bug 921120, we will need to update the arguments analysis first.
The restructuring happened as follows:
info().argsObjAliasesFormals()
and info().argumentsAliasesFormals()
both
imply info().hasArguments()
, so when we handle !info().hasArguments()
first,
we just need to emit current->setArg(arg)
and can then directly return.
Furthermore info().argsObjAliasesFormals()
and info().argumentsAliasesFormals()
also imply mapped arguments semantics, so we handle !info().hasMappedArgsObj()
next and abort the Ion compilation. This is just done to match the current
behaviour and should be removed in a follow-up patch!
When we're running the arguments analysis, info().needsArgsObj()
is true, so
we always end up with emitting MSetArgumentsObjectArg
. The arguments analysis
will then flag the arguments object as being needed, cf. ArgumentsUseCanBeLazy()
.
That means info().needsArgsObj()
is always true at this point, whether or not
we're currently running the arguments analysis.
Depends on D64568
Assignee | ||
Comment 4•5 years ago
|
||
Part 3 removed the only place where MSetFrameArgument instructions were created.
Depends on D64569
Assignee | ||
Comment 5•5 years ago
|
||
This comment dates back to before bug 921120 and bug 995336 were written and no
longer makes any sense with the current implementation.
Depends on D64570
Assignee | ||
Comment 6•5 years ago
|
||
We don't create lazy arguments when JSOp::SetArg
is present, which means
modifiesArguments()
is always false
in this method.
Depends on D64571
Assignee | ||
Comment 7•5 years ago
|
||
Looks like this should be unaliasedActual()
, when interpreting this changeset
correctly:
https://hg.mozilla.org/mozilla-central/rev/adcd5d3c984efef3688189b11c6ec6276ad014c8
Drive-by change: Remove a stray, commented out code line.
Depends on D64572
Comment 9•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b0b1bbf5387c
https://hg.mozilla.org/mozilla-central/rev/3d52ff211475
https://hg.mozilla.org/mozilla-central/rev/8a3508d85549
https://hg.mozilla.org/mozilla-central/rev/b89721d62b74
https://hg.mozilla.org/mozilla-central/rev/84d19c5c6a7a
https://hg.mozilla.org/mozilla-central/rev/699e15941bae
https://hg.mozilla.org/mozilla-central/rev/c367dad82129
Updated•5 years ago
|
Description
•