Thanks for the review Søren.
I did not know about the x64 jump table. I refactored the code to use the
same
mechanism, generating the table at the end of the code as you suggested.
This is
indeed simpler.
The updated patch should be uploaded soon.
Alexandre
On 2011/05/16 07:26:39, Søren Gjesse wrote:
Please look into having the jump table at the end of the generated
optimized
code instead of inside the constant pool.
http://codereview.chromium.org/7021007/diff/1/src/arm/assembler-arm.cc
File src/arm/assembler-arm.cc (right):
http://codereview.chromium.org/7021007/diff/1/src/arm/assembler-arm.cc#newcode2649
src/arm/assembler-arm.cc:2649: // Emit the deoptimization jump table.
This emitting of the deopt-jump table in parts inside the constant pool
looks
a
bit complicated. Also we didn't used to have code in the constant pool.
How about placing the whole jump table at the end of the code instead of
interleaving it inside the constant pools?
We will have to limit the max size of the generated code for optimized
functions, but I don't think that is a problem.
http://codereview.chromium.org/7021007/diff/1/src/arm/assembler-arm.cc#newcode2669
src/arm/assembler-arm.cc:2669: ASSERT(is_int24(imm24));
Please use the CodePatcher class for this.
CodePatcher patcher(pc, 1);
patcher.masm()->b(...)
http://codereview.chromium.org/7021007/diff/1/src/arm/lithium-codegen-arm.cc
File src/arm/lithium-codegen-arm.cc (right):
http://codereview.chromium.org/7021007/diff/1/src/arm/lithium-codegen-arm.cc#newcode605
src/arm/lithium-codegen-arm.cc:605: } else {
The x64 also uses a jump table, which is emitted at the end of the
generated
code. It also tries to use the same table slot more than once, as there
often
are several deopts to the same entry.
http://codereview.chromium.org/7021007/
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
