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

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructions.cc#newcode1628
src/hydrogen-instructions.cc:1628: case MAP_TRANSITION:
On 2012/05/02 13:55:00, Sven Panne wrote:
On 2012/05/02 13:39:29, Michael Starzinger wrote:
> I think that check is not general enough. We have a transition
whenever
> "lookup.IsFound() && !lookup.IsProperty()". Esepcially with Sven's
new
accessor
> pairs in mind.

Michael's comment is correct, but things are even more tricky, because
the
PropertyType alone is not enough to decide if we have a transition or
not: In
the CALLBACKS case you have to look into the AccessorPair to decide if
we have a
transition or not. And without a holder (see "NULL" above), this won't
work...
(see LookupResult::IsProperty).

All I want to do is to ignore this particular map when generating
optimized code.  If we actually encounter it we will deopt.  I don't
actually care much whether there is a real map transition from this map
to another one.

https://chromiumcodereview.appspot.com/10306010/diff/1/src/hydrogen-instructions.cc#newcode1633
src/hydrogen-instructions.cc:1633: default:
On 2012/05/02 13:55:00, Sven Panne wrote:
We should never use a default case when doing a switch over the
property type,
because this makes finding all the places where things have to be
changed when
fiddling around with those types (e.g. adding a new type, changing the
behaviour
for a given type, etc.) virtually impossible. I've been down that road
several
times in the last few months... :-P

I didn't add this default clause.  All it is saying is that if there is
another kind of property then Crankshaft does not understand it and will
not generate optimized code for it.  If a new kind of property is added
this is certainly the correct behaviour, so I see no reason to change
this, but you are welcome to try in a different CL.

https://chromiumcodereview.appspot.com/10306010/

--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev

Reply via email to