http://codereview.chromium.org/6879081/diff/1/src/arm/code-stubs-arm.cc File src/arm/code-stubs-arm.cc (right):
http://codereview.chromium.org/6879081/diff/1/src/arm/code-stubs-arm.cc#newcode1983 src/arm/code-stubs-arm.cc:1983: if (!mode_ == UNARY_OVERWRITE) { On 2011/04/20 20:27:50, Sven wrote:
On 2011/04/20 19:13:30, Erik Corry wrote: > !mode_ == should be mode_ !=
... or even clearer: mode == UNARY_NO_OVERWRITE (Uncle Bob says: Don't
use
negation ;-) My code was based on GenericUnaryOpStub::Generate, which
has a
similar comparison, but I guess that GenericUnaryOpStub can be nuked
soon,
anyway.
Silly C++ type system lets you do ! to an enum :-( http://codereview.chromium.org/6879081/diff/1/src/arm/code-stubs-arm.cc#newcode1987 src/arm/code-stubs-arm.cc:1987: __ AllocateHeapNumber(r2, r3, r4, r6, slow); On 2011/04/20 20:27:50, Sven wrote:
On 2011/04/20 19:13:30, Erik Corry wrote: > This will generate a type transition on a GC. That gives wrong type
feedback
to > the Cranker because it goes generic.
I don't understand that one. Could you elaborate, please?
If the stub encounters something that is not a number on the input side then it should transition the stub call site to the generic state. This tells a later Crankshaft code generation routine to call the stub at this point since the inlined Crankshaft code can only cope with numbers and would cause an expensive deopt if another nonnumber came along. On the other hand a failure to bump-allocate a heap number doesn't tell us anything that we need to communicate to Crankshaft. It just means that we coincidentally hit the end of newspace here. In this case we need to cause a GC and return the correct answer, but we don't need to transition the stub call site into the generic state. Going generic would cause needlessly suboptimal code to be generated by Crankshaft. Perhaps this flaw is shared by the binary version? There is a runtime call that merely allocates a heap number, possibly doing a GC. You can use that. http://codereview.chromium.org/6879081/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
