Thanks Ulan!
https://codereview.chromium.org/255343004/diff/40001/src/arm64/macro-assembler-arm64.cc
File src/arm64/macro-assembler-arm64.cc (right):
https://codereview.chromium.org/255343004/diff/40001/src/arm64/macro-assembler-arm64.cc#newcode1264
src/arm64/macro-assembler-arm64.cc:1264: Msr(FPCR, fpcr);
On 2014/05/02 09:10:33, ulan wrote:
AssertFPCRState also checks flush-to-zero and rounding mode, but this
function
doesn't. Is this asymmetry because we do not restore FPCR and changing
rounding
mode could lead to more incorrect results than changing NAN mode?
Could you please add comment explaining that?
The flush-to-zero and rounding mode settings are left at the default
value, so AssertFPCRState checks that the default is appropriate. (The
simulator doesn't support non-default values for those bits anyway).
Also, yes, we would get incorrect results even in C++ code if we changed
those bits: JavaScript requires subnormal support (not-flush-to-zero)
and round-to-nearest mode for almost all arithmetic operations.
I'll add a comment.
https://codereview.chromium.org/255343004/diff/40001/src/arm64/macro-assembler-arm64.cc#newcode1275
src/arm64/macro-assembler-arm64.cc:1275: // With DN=1 and
RMode=FPTieEven, subtracting 0.0 preserves all inputs expect
On 2014/05/02 09:10:33, ulan wrote:
s/expect/except
Done.
https://codereview.chromium.org/255343004/
--
--
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.
