Add and use ElementsKind side effect

Add and use ElementsKind side effect

Also partition side effects into observable and not observable, with only observable requiring Simulates and non-observable changes able to participate in GVN and code hoisting.

BUG=none
TEST=none

Committed: http://code.google.com/p/v8/source/detail?r=9847

[danno, 2011-10-24 21:28:36]

Please take a look. This change prevents invalid reuse of elements after
ElementsKindTransitions. To make that work, it allows hoisting and GVN on values
that have side effects but don't make "observable" changes (feel free to suggest
another name). These side effects don't require Simulates.

Downside: GVN must be done repeatedly, since removing values with side effects
enable further GVN.

[fschneider, 2011-10-27 15:58:22]

http://codereview.chromium.org/8380017/diff/1007/src/hydrogen.cc
File src/hydrogen.cc (right):

http://codereview.chromium.org/8380017/diff/1007/src/hydrogen.cc#newcode1396
src/hydrogen.cc:1396: while (!done_) {
Couldn't you just do 2 rounds at most? First you hoist HTransitionElements out
of loops, then hoist depending instructions in the second round. After that I
don't see how more opportunities would arrive.

http://codereview.chromium.org/8380017/diff/1007/src/hydrogen.cc#newcode4142
src/hydrogen.cc:4142: object = AddInstruction(new(zone())
HTransitionElementsKind(
I'm not sure, if it ther is any benefit to emit a sequence of individual
HTransitionElementsKind instructions, instead of one macro-instruction that
handles all maps.

 As I understand they are either all hoisted out of a loop or none of them,
aren't they?

[danno, 2011-10-28 07:29:52]

Please take another look

http://codereview.chromium.org/8380017/diff/1007/src/hydrogen.cc
File src/hydrogen.cc (right):

http://codereview.chromium.org/8380017/diff/1007/src/hydrogen.cc#newcode1396
src/hydrogen.cc:1396: while (!done_) {
On 2011/10/27 15:58:22, fschneider wrote:
> Couldn't you just do 2 rounds at most? First you hoist HTransitionElements out
> of loops, then hoist depending instructions in the second round. After that I
> don't see how more opportunities would arrive.

Done, although I don't know if the more general approach has a downside, and if
in the future there are more values of this type added, the fixed-point
iteration would already work.

http://codereview.chromium.org/8380017/diff/1007/src/hydrogen.cc#newcode4142
src/hydrogen.cc:4142: object = AddInstruction(new(zone())
HTransitionElementsKind(
I don't think this is necessarily a good idea. If there are multiple polymorphic
element access sites in a loop, each using a different combination of from and
to transition maps, then the current approach will create the minimal set of
transitions because each map transition is a separate instruction. A more
"chunky" approach would not be able to recognize congruent element transitions
in that case of the exact set of maps at two different polymorphic sites differs
even if only by a single map.

On 2011/10/27 15:58:22, fschneider wrote:
> I'm not sure, if it ther is any benefit to emit a sequence of individual
> HTransitionElementsKind instructions, instead of one macro-instruction that
> handles all maps.
> 
>  As I understand they are either all hoisted out of a loop or none of them,
> aren't they?

[fschneider, 2011-10-28 11:38:58]

lgtm