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#newcode1987 src/arm/code-stubs-arm.cc:1987: __ AllocateHeapNumber(r2, r3, r4, r6, slow); On 2011/04/21 02:48:57, Erik Corry wrote:
[...] 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.
OK, understood.
Perhaps this flaw is shared by the binary version?
Nope, but it is shared by my unary minus implementation, too, of course on all 3 platforms... :-P
There is a runtime call that merely allocates a heap number, possibly
doing a
GC. You can use that.
The existing code is a bit hard to grasp because there is a plethora of allocation functions available. Furthermore, I can't find a documentation which function/runtime call/builtin uses/clobbers which register. In addition, code generation is complicated by the fact that a full nursery "shines through" via gc_required, something I believe can be avoided. Nevertheless, I'll give it a try... :-) http://codereview.chromium.org/6879081/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
