-
-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize integer negation #1464
Conversation
Test262 conformance changes:
|
23e99eb
to
bdd3596
Compare
Benchmark for 49fececClick to view benchmark
|
Benchmark for bc2c790Click to view benchmark
|
Interestingly, it's failing 4 tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I extracted one of the checks in the failing test:
if (-1 % -1 !== -0) {
$ERROR('#2.1: -1 % -1 === 0. Actual: ' + (-1 % -1));
} else {
if (1 / (-1 % -1) !== Number.NEGATIVE_INFINITY) {
$ERROR('#2.2: -1 % -1 === - 0. Actual: +0');
}
}
EcmaScript requires that -1 % -1
must have the information of the sign in order to return f64::NEGATIVE_INFINITY
in case we divide a number by -1 % -1
.
With the changes on this commit, -1i32 % -1i32
returns 0i32
, making 1 / (-1 % -1) === f64::POSITIVE_INFINITY
. This fails the second check.
So, to pass this test we would need to change the rem
operator to return a -0.0f64
if x < 0
in x % y === 0
Nonetheless, it's still necessary to convert -0
to f64
to pass the other test.
Yup. The integer module operation is not spec compliant, ill try to look into it this weekend |
bdd3596
to
f14ac7e
Compare
f14ac7e
to
10dc64b
Compare
Fixed the mod operator. |
It changes the following:
%
operator to return a number with the sign of its lhs.