On 2015/01/29 at 08:14:08, dtc-v8 wrote:
Thank you for the feedback.
There was a problem with the difference between the int32 addition the
int64
address calculation - the 32 bit argument to the addition operation is not
sign
extended when used in an 64 bit address calculation operation so the
calculation
failed when it was negative. The constant offset is sign extended. It
appears
that a simple type check can avoid this by only applying the optimization
when
the argument to the 32 bit addition operation is not negative. Some source
comments have been added to explain this.
Can you see any other issues?
It may well be cleaner to transform the int32 addition to an int64
addition
earlier and I'll give this a try too.
Well, the problem is still the same:
ChangeUint32ToUint64(Int32Add(x,y)) is not equivalent to
Int64Add(ChangeUint32ToUint64(x), ChangeUint32ToUint64(y)), but to
Word64And(Int64Add(ChangeUint32ToUint64(x), ChangeUint32ToUint64(y)),
0xffffffff), so the optimization itself is unsound. It might be safe for
asm.js
heap access patterns, where we end with Load/Store operations, but in
general
that's not true.
https://codereview.chromium.org/860283004/
--
--
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.
