346915 - Optimized "delete" expressions can often be optimized further

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P4)

Description

[Jesse Ruderman]

> function() { delete 3; }
function () { true; }

> function () { true; }
function () { }

Why isn't it optimized all the way to function () { } in the first round?

Comment 1

[Brendan Eich [:brendan]]

(In reply to comment #0)
> Why isn't it optimized all the way to function () { } in the first round?

Constant folder doesn't handle delete rvalue, so we end up with peephole optimization, which is also independent of the useless expression eliminator. Taking, the decompiler is my red-headed stepchild.

/be

Comment 2

[Brendan Eich [:brendan]]

Attachment: fix

Comment 3

[Brendan Eich [:brendan]]

Fixed on the trunk.

/be

Comment 4

[Brendan Eich [:brendan]]

Comment on attachment 237085 [details] [diff] [review]
fix 

This is a safe fix for the fuzz tester.  It's larger looking than its effects: it does not change CheckSideEffects' behavior on delete expressions except where the operand is not an "lvalue" -- in which case it makes CheckSideEffects consistent with the code generator, so that we don't end up with useless true operators that are culled on a round-trip throught the decompiler.

/be

Comment 5

[Mike Schroepfer]

Comment on attachment 237085 [details] [diff] [review]
fix 

a=schrep for drivers.

Comment 6

[Brendan Eich [:brendan]]

Fixed on the 1.8 branch.

/be

Comment 7

[Bob Clary [:bc] (inactive)]

Checking in regress-346915.js;
/cvsroot/mozilla/js/tests/js1_5/Regress/regress-346915.js,v  <--  regress-346915.js
initial revision: 1.1

Comment 8

[Bob Clary [:bc] (inactive)]

verified fixed 1.8, 1.9 20060909 windows/mac*/linux