[Webkit-unassigned] [Bug 20764] Proposed byte-code optimization framework

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20764


ggaren at apple.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23322|review?                     |review-
               Flag|                            |




------- Comment #10 from ggaren at apple.com  2008-10-24 13:33 PDT -------
(From update of attachment 23322)
I'm going to r- this because I don't want to add this kind of complexity to the
engine without a measurable speedup.

Here's a simple suggestion for a place to start (inspired by what you've
posted):
- annotate each opcode with a length
- change CodeBlock::dump, CTI::privateCompile*, etc. -- anything that iterates
bytecode -- to use the abstract length annotations instead of hard-coded
constants

That will allow you to land parts of this patch while reducing, rather than
increasing, complexity.

Then, for a speedup:
- annotate each opcode with
    1) a flag indicating whether the opcode has a destination, which, if true,
means that operand 0 holds the destination register
    2) a list of source operands (or maybe an enum of Unary | Binary | Ternary
| etc. with canonical source operand locations
- change programs to issue explicit op_load instructions to initialize their
variables to undefined
- add an optimization pass to the CodeGenerator that iterates up to the first
label and removes any op_load instructions to a destinations that are written
before they are read

This should substantially improve code like:
var x = 1;
var y = 2;
...
by removing the need to initialize x and y to undefined.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.