| Summary: | DFG bytecode parser should record the places where bytecode operands die and this should be preserved by write(SideState)/NodeMustGenerate | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Filip Pizlo <fpizlo> | ||||||
| Component: | JavaScriptCore | Assignee: | Filip Pizlo <fpizlo> | ||||||
| Status: | NEW --- | ||||||||
| Severity: | Normal | ||||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 143734 | ||||||||
| Attachments: |
|
||||||||
|
Description
Filip Pizlo
2015-04-16 11:27:44 PDT
Created attachment 250962 [details]
work in progress
Starting to pass tests.
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.
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. 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. |