I addressed these new comments. The updated patch should be uploaded soon.
Alexandre http://codereview.chromium.org/7021007/diff/11004/src/arm/assembler-arm.h File src/arm/assembler-arm.h (right): http://codereview.chromium.org/7021007/diff/11004/src/arm/assembler-arm.h#newcode1223 src/arm/assembler-arm.h:1223: static int MaxNumPRInfo() { return kMaxNumPRInfo; } Done. I hesitated to do so as everything was declared together. Rodolph is working on patch to clean up the relocation information on ARM. Renaming this is part of the clean-up patch I believe. On 2011/05/18 06:47:13, Søren Gjesse wrote:
No need to make accessors for constants - just make it public. However
the name
is quite strange, and will not make much sense. After all I don't
think we need
it - see later comments.
http://codereview.chromium.org/7021007/diff/11004/src/arm/lithium-codegen-arm.cc File src/arm/lithium-codegen-arm.cc (right): http://codereview.chromium.org/7021007/diff/11004/src/arm/lithium-codegen-arm.cc#newcode271 src/arm/lithium-codegen-arm.cc:271: // We also need to check that the jump table will require fewer constant Removed. On 2011/05/18 06:47:13, Søren Gjesse wrote:
I think we can avoid this restriction - see below.
http://codereview.chromium.org/7021007/diff/11004/src/arm/lithium-codegen-arm.cc#newcode284 src/arm/lithium-codegen-arm.cc:284: __ bind(&deopt_jump_table_[i].label); Done. I also moved back the forced emission of the constant pool in the deferred code generation. It puts a heavier burden on the previous check, but that should never be a problem. It is also worth noting that - if we ever need it - we could go around the first constraint by generating jump tables regularly instead of only at the end of the code. On 2011/05/18 06:47:13, Søren Gjesse wrote:
How about avoiding using the const pool all together by emitting a -4
pc
relative load of pc for each table entry.
ldr pc, [pc, #-4] <address of deopt table entry 0> ldr pc, [pc, #-4] <address of deopt table entry 1> ...
http://codereview.chromium.org/7021007/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
