[webkit-reviews] review denied: [Bug 20764] Proposed byte-code optimization framework : [Attachment 23322] fixed up patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 24 13:33:59 PDT 2008

Geoffrey Garen <ggaren at apple.com> has denied 's request for review:
Bug 20764: Proposed byte-code optimization framework

Attachment 23322: fixed up patch

------- Additional Comments from Geoffrey Garen <ggaren at apple.com>
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
- 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

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.

More information about the webkit-reviews mailing list