Pass checked values to HLoadNamedField, removing the need for extra type-check field.

Pass checked values to HLoadNamedField, removing the need for extra type-check field.

R=titzer@chromium.org

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

[Toon Verwaest, 2013-08-12 15:38:12]

PTAL

[titzer, 2013-08-21 14:07:55]

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen-escape-an...
File src/hydrogen-escape-analysis.cc (right):

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen-escape-an...
src/hydrogen-escape-analysis.cc:218: ASSERT(load->object() == mapcheck);
Since a load now only has one input, isn't this assert redundant?

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen.cc
File src/hydrogen.cc (right):

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen.cc#newcod...
src/hydrogen.cc:1225: HCheckMaps* checked_value,
s/checked_value/checked_object/g ?

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen.cc#newcod...
src/hydrogen.cc:4602: Add<HCheckMaps>(object, types);
I'm not quite sure where the result of this guy should be fed. Who consumes the
object afterwards?

[Toon Verwaest, 2013-08-21 14:28:43]

PTAL

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen-escape-an...
File src/hydrogen-escape-analysis.cc (right):

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen-escape-an...
src/hydrogen-escape-analysis.cc:218: ASSERT(load->object() == mapcheck);
On 2013/08/21 14:07:56, titzer wrote:
> Since a load now only has one input, isn't this assert redundant?

Done.

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen.cc
File src/hydrogen.cc (right):

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen.cc#newcod...
src/hydrogen.cc:1225: HCheckMaps* checked_value,
On 2013/08/21 14:07:56, titzer wrote:
> s/checked_value/checked_object/g ?

Done.

https://chromiumcodereview.appspot.com/22831003/diff/1/src/hydrogen.cc#newcod...
src/hydrogen.cc:4602: Add<HCheckMaps>(object, types);
The problem is that we have a checkmap, and then we could load the prototype
from the map; but given that it's a constant, we rather just inline the
prototype as a constant directly. An HConstant doesn't have a dependency;
because it's constant anyway.

I agree, the problem is that the prototype is only that constant if the
HCheckMaps of the receiver succeeded. This goes even further however. When we
check the prototype chain, we have a list of HCheckMaps(HConstant(p),
expected_map_for_p);, which can even be removed (replaced by a code dependency)
if the map of p is "stable".

This CL doesn't fix that problem; but it does at least let the HLoadNamedField
below depend on the right mapcheck; the check of the prototype from which we
load the value.

On 2013/08/21 14:07:56, titzer wrote:
> I'm not quite sure where the result of this guy should be fed. Who consumes
the
> object afterwards?

[titzer, 2013-08-21 14:43:44]

lgtm

[Toon Verwaest, 2013-08-21 14:50:06]

Committed patchset #2 manually as r16260.