Remove write-barriers for stores to new-space objects.

Remove write-barriers for stores to new-space objects.

This change allows hydrogen instructions to keep track of instructions
that dominate certain side-effects (GVN flags) in the hydrogen graph. We
use the GVN pass to keep track of side-effects because accurate flags
are already in place.

It also adds a new side-effect (kChangesNewSpacePromotion) indicating
whether an instruction can cause a GC and have objects be promoted to
old-space. An object allocated in new-space is sure to stay on paths not
having said side-effect.

R=erik.corry@gmail.com
TEST=mjsunit/compiler/inline-construct

Committed: https://code.google.com/p/v8/source/detail?r=11270

[Erik Corry, 2012-04-10 12:06:52]

LGTM

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
File src/hydrogen-instructions.h (right):

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
src/hydrogen-instructions.h:523: #undef COUNT_FLAG
I think it would be nice to provide functions:

GVNFlag ChangesFlagFromInt(int x) { return x * 2; }
GVNFlag DependsOnFlagFromInt(int x) { return x * 2 + 1; }

and then use them instead of just multiplying by 2, which is fairly opaque.

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
src/hydrogen-instructions.h:804: result.Remove(kChangesNewSpace);
The name makes it sound like any write to new space is tracked, but actually it
is just tracking whether anything might happen to promote objects from new
space.  Would kChangesNewSpacePromotion be better?

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
src/hydrogen-instructions.h:4053: offset_(offset) {
Should you not initialize new_space_dominator_ here?

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen.cc
File src/hydrogen.cc (right):

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen.cc#new...
src/hydrogen.cc:1700: HSideEffectMap& dominators) {
This should be a pointer argument:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Reference_Argu...

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen.cc#new...
src/hydrogen.cc:1741: GVNFlag depends_on_flag = static_cast<GVNFlag>(i * 2 + 1);
This would be cleaner with a variable to hold dominators[i] that you can use in
the 4 places below.

[Michael Starzinger, 2012-04-11 09:53:08]

Added new patch set.

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
File src/hydrogen-instructions.h (right):

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
src/hydrogen-instructions.h:523: #undef COUNT_FLAG
On 2012/04/10 12:06:52, Erik Corry wrote:
> I think it would be nice to provide functions:
> 
> GVNFlag ChangesFlagFromInt(int x) { return x * 2; }
> GVNFlag DependsOnFlagFromInt(int x) { return x * 2 + 1; }
> 
> and then use them instead of just multiplying by 2, which is fairly opaque.

Done.

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
src/hydrogen-instructions.h:804: result.Remove(kChangesNewSpace);
On 2012/04/10 12:06:52, Erik Corry wrote:
> The name makes it sound like any write to new space is tracked, but actually
it
> is just tracking whether anything might happen to promote objects from new
> space.  Would kChangesNewSpacePromotion be better?

Done.

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen-instru...
src/hydrogen-instructions.h:4053: offset_(offset) {
On 2012/04/10 12:06:52, Erik Corry wrote:
> Should you not initialize new_space_dominator_ here?

Done.

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen.cc
File src/hydrogen.cc (right):

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen.cc#new...
src/hydrogen.cc:1700: HSideEffectMap& dominators) {
On 2012/04/10 12:06:52, Erik Corry wrote:
> This should be a pointer argument:
>
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Reference_Argu...

Done.

https://chromiumcodereview.appspot.com/10031031/diff/1001/src/hydrogen.cc#new...
src/hydrogen.cc:1741: GVNFlag depends_on_flag = static_cast<GVNFlag>(i * 2 + 1);
On 2012/04/10 12:06:52, Erik Corry wrote:
> This would be cleaner with a variable to hold dominators[i] that you can use
in
> the 4 places below.

Done.