Bug 143833 - DFG bytecode parser should record the places where bytecode operands die and this should be preserved by write(SideState)/NodeMustGenerate
Summary: DFG bytecode parser should record the places where bytecode operands die and ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Filip Pizlo
URL:
Keywords:
Depends on:
Blocks: 143734
  Show dependency tree / graph
 
Reported: 2015-04-16 11:27 PDT by Filip Pizlo
Modified: 2015-04-19 15:28 PDT (History)
0 users

See Also:

Attachments
work in progress (47.03 KB, patch)
2015-04-16 15:56 PDT, Filip Pizlo 		no flags Details | Formatted Diff | Diff
passing some tests (61.86 KB, patch)
2015-04-19 14:19 PDT, Filip Pizlo 		no flags Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2015-04-16 11:27:44 PDT 
...
Comment 1 Filip Pizlo 2015-04-16 15:56:35 PDT 
Created attachment 250962 [details]
work in progress

Starting to pass tests.
Comment 2 Filip Pizlo 2015-04-19 14:19:15 PDT 
Created attachment 251128 [details]
passing some tests

Still need to test more things and run benchmarks.  The perf impact of this is the insertion of additional nodes and the fact that block->last() is no longer a terminal.  Getting the terminal requires a small backwards search.
Comment 3 Filip Pizlo 2015-04-19 14:47:33 PDT 
I'm no longer sure about this.  It appears to require some dirty logic for inserting the KillHints in the "right" places and then maintaining them through transformations.  It would be super awesome if we could just use FullBytecodeLiveness.
Comment 4 Filip Pizlo 2015-04-19 15:28:31 PDT 
The point of inserting KillHints was that this was supposed to be faster than consulting FullBytecodeLiveness late in the game.  But, as far as I can tell, even inserting KillHints incurs a 1% loss on SunSpider.

I'm going to factor out the sloppy-terminal part of this patch.  Hopefully that is not responsible for any slow-down.  If it's not, then I'll move on to writing a Phantom inserter based on FullBytecodeLiveness.  Then I'll try to make that as fast as possible.  It seems like it shouldn't have to be slow - after all, liveness over bytecode is just fun with bitvectors.