Bug 223278 - DFG arity fixup nodes should exit to the caller's call opcode
Summary: DFG arity fixup nodes should exit to the caller's call opcode
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Keith Miller
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-03-16 14:06 PDT by Keith Miller
Modified: 2022-01-21 02:38 PST (History)
8 users (show)

See Also:


Attachments
Patch (7.71 KB, patch)
2021-03-31 09:19 PDT, Keith Miller
no flags Details | Formatted Diff | Diff
Patch for landing (8.03 KB, patch)
2021-04-05 11:30 PDT, Keith Miller
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Keith Miller 2021-03-16 14:06:04 PDT
DFG arity fixup nodes should exit to the caller's call opcode
Comment 1 Radar WebKit Bug Importer 2021-03-23 14:07:13 PDT
<rdar://problem/75754212>
Comment 2 Keith Miller 2021-03-31 09:19:39 PDT
Created attachment 424777 [details]
Patch
Comment 3 Saam Barati 2021-03-31 12:11:24 PDT
Comment on attachment 424777 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=424777&action=review

> Source/JavaScriptCore/ChangeLog:29
> +        --> foo: loc10 is a local in foo.
> +            ...
> +            1: MovHint(loc10)
> +            2: SetLocal(loc10)
> +        <-- foo // loc10 ten is now out of scope for the InlineCallFrame of the caller.
> +        ...
> +        // Phantom will be inserted here refering to loc10, which doesn't make sense.
> +        --> bar // loc10 is an argument to bar and needs arity fixup.
> +            ... // All of these nodes are ExitInvalid
> +            3: MovHint(loc10, ExitInvalid)
> +            4: SetLocal(loc10, ExitInvalid)
> +            ...

How does changing the exit origin fix this?

> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:1730
> +    // In this example phantom insertion phase will think @3 is always alive because it's in the header of bar. So,
> +    // it will think we are about to kill the old value and thus need a Phantom. That Phantom, however, may be inserted
> +    // into the caller's NodeOrigin (all the nodes in bar before @3 are ExitInvalid), which doesn't know about loc10.

how does setting the exit origin fix this?
Comment 4 Keith Miller 2021-04-05 11:16:36 PDT
Comment on attachment 424777 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=424777&action=review

>> Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:1730
>> +    // into the caller's NodeOrigin (all the nodes in bar before @3 are ExitInvalid), which doesn't know about loc10.
> 
> how does setting the exit origin fix this?

Since PhantomInsertionPhase asks forAllKilledOperands what locals have been killed at any given Node and loc10 is in the header of bar loc10 will go from being considered dead in the caller to alive again in the callee (and killed at @3). By setting the exit origin to the caller's frame for arity fixup loc10 will not be seen as alive into @3 anymore. I'll add this to the comment.
Comment 5 Keith Miller 2021-04-05 11:30:05 PDT
Created attachment 425177 [details]
Patch for landing
Comment 6 EWS 2021-04-05 18:52:11 PDT
Committed r275472: <https://commits.webkit.org/r275472>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 425177 [details].