Fix GVN for loops.

Fix GVN for loops.

[ngeoffray, 2012-06-17 23:28:41]

Hi Mads! Couldn't resist finding out what went wrong with your CL :) This patch
should fix it: we were not using the loop change flags when trying to gvn
instructions of a loop. So an instruction in a loop was able to be GVN'ed with
another instruction before the loop, even though the loop contains side effects
after the instruction.

I won't commit this patch, so feel free to use it and hopefully there won't be
any failure anymore (annoying that it was a browser test that revealed the
problem).

[kasperl, 2012-06-18 05:51:33]

LGTM.

https://chromiumcodereview.appspot.com/10565025/diff/1/lib/compiler/implement...
File lib/compiler/implementation/ssa/optimize.dart (right):

https://chromiumcodereview.appspot.com/10565025/diff/1/lib/compiler/implement...
lib/compiler/implementation/ssa/optimize.dart:945:
successorValues.kill(changesFlags);
Would it make sense to do a fast check (changesFlags == 0) here too? Or should
we move the check to ValueSet.kill instead (early bailout)?

[kasperl, 2012-06-18 07:06:56]

... and I hope I can convince Mads to land this :-)

[Mads Ager (google), 2012-06-18 07:13:45]

LGTM. I'll incorporate this into the other change and land. Thanks Nicolas! :)

[Mads Ager (google), 2012-06-18 08:01:13]

https://chromiumcodereview.appspot.com/10565025/diff/1/lib/compiler/implement...
File lib/compiler/implementation/ssa/optimize.dart (right):

https://chromiumcodereview.appspot.com/10565025/diff/1/lib/compiler/implement...
lib/compiler/implementation/ssa/optimize.dart:945:
successorValues.kill(changesFlags);
On 2012/06/18 05:51:33, kasperl wrote:
> Would it make sense to do a fast check (changesFlags == 0) here too? Or should
> we move the check to ValueSet.kill instead (early bailout)?

Added early bailout to ValueSet.kill and called it unconditionally in all three
places.