Hi Danno,
Yes, the result may be not in the register. I add the support to check
IsRegister, otherwise sign extend the 32 bit in the stack slot.
But I only find the possible candidates are HParameter and HUnknownOSRValue,
whose result is not in the register. Both representation of them are
Tagged. And
considering the int32 requirement for key value in LoadKeyed/StoreKeyed,
there
is always tagged-to-i conversion between HParameter/HUnknownOSRValue and
LoadKeyed/StoreKeyed. So the sign extension works upon tagged-to-i.
I tried OSR, context variance and HParameter etc, but have not yet find any
available test case. Do I miss someting?
https://codereview.chromium.org/179773002/diff/90001/src/x64/lithium-codegen-x64.cc
File src/x64/lithium-codegen-x64.cc (right):
https://codereview.chromium.org/179773002/diff/90001/src/x64/lithium-codegen-x64.cc#newcode279
src/x64/lithium-codegen-x64.cc:279: __ movsxlq(result_reg, result_reg);
On 2014/03/19 09:16:43, danno wrote:
I think it is possible for results to be allocated on the stack on
ia32 and x64
under certain circumstances, and in those cases I think this will
fail. It might
be tricky to construct such a case, but this code will for fail for
it. There
should be a test for IsRegister, and if the results is not a register,
you will
need to sign-extend the correct 32-bits of the stack slot.
A test case for that case would be very useful, too.
Done.
https://codereview.chromium.org/179773002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
