https://chromiumcodereview.appspot.com/10831049/diff/1/src/arm/lithium-codegen-arm.cc File src/arm/lithium-codegen-arm.cc (right):
https://chromiumcodereview.appspot.com/10831049/diff/1/src/arm/lithium-codegen-arm.cc#newcode2793 src/arm/lithium-codegen-arm.cc:2793: if (instr->hydrogen()->key()->representation().IsTagged()) { Actually, this does get triggered. It's scary. The HLoadKeyedFastElement instruction depends on the BoundsCheck instruction. The representation type of the bounds check isn't important, but it has to be consistent with the index input to the load. During the phase that eliminates redundant bounds checks, the key input to the load is replaced by the input to the boundscheck, which can be tagged. Adding a comment to this effect. On 2012/07/30 11:58:08, Jakob wrote:
I don't see how this condition can ever be true.
HLoadKeyedFastElements forces
Integer32 representation for its |key| input.
https://chromiumcodereview.appspot.com/10831049/diff/1/src/arm/lithium-codegen-arm.cc#newcode2802 src/arm/lithium-codegen-arm.cc:2802: Operand(instr->additional_index() << kPointerSizeLog2)); I changed this here and in the DoStoreKeyedFastElement code to be consistent (I copied it here from there originally to make sure the cases were handled identically). On 2012/07/30 11:58:08, Jakob wrote:
What's the benefit of having this addition in generated code here? instr->additional_index() is a constant; adding it to
FixedArray::kHeaderSize at
Hydrogen runtime seems fine to me.
Done. https://chromiumcodereview.appspot.com/10831049/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
