fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
Tests that -2^31/-1 (and a bunch of other corner cases) does the right thing.
|
2012-03-21 01:29:28 +00:00
|
|
|
|
|
|
|
|
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2
|
|
|
|
|
PASS myOtherDivByNeg1(w) is -4
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is -1073741824
|
|
|
|
|
PASS myOtherMod(w, v) is 0
|
|
|
|
|
PASS myOtherModByNeg1(w) is 0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 10:07:14 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myDiv(x, y) is 2147483648
|
|
|
|
|
PASS myDivByNeg1(x) is 2147483648
|
|
|
|
|
PASS myDivNeg2ToThe31(y) is 2147483648
|
|
|
|
|
PASS myMod(x, y) is -0
|
|
|
|
|
PASS myMod(x, z) is -2
|
|
|
|
|
PASS myModByNeg1(x) is -0
|
fourthTier: clean up ArithDiv/ArithMod in the DFG
https://bugs.webkit.org/show_bug.cgi?id=116793
Source/JavaScriptCore:
Reviewed by Mark Hahnenberg.
This makes ArithDiv and ArithMod behave similarly, and moves both of their
implementations entirely into DFGSpeculativeJIT.cpp into methods named like
the ones for ArithSub/ArithMul.
Specifically, ArithMod now uses the wrap-in-conversion-nodes idiom that
ArithDiv used for platforms that don't support integer division. Previously
ArithMod had its own int-to-double and double-to-int conversions for this
purpose.
As well, this gets rid of confusing methods like compileSoftModulo() (which
did no such thing, there wasn't anything "soft" about it) and
compileIntegerArithDivForX86() (which is accurately named but we don't use
the platform-specific method convention anywhere else).
Finally, this takes the optimized power-of-two modulo operation that was
previously only for ARMv7s, and makes it available for all platforms. Well,
sort of: I actually rewrote it to do what latest LLVM appears to do, which
is a crazy straight-line power-of-2 modulo based on a combination of shifts,
ands, additions, and subtractions. I can kind of understand it well enough
to see that it complies with both C and JS power-of-2 modulo semantics. I've
also confirmed that it does by testing (hence the corresponding improvements
to one of the division tests). But, I don't claim to know exactly how this
code works other than to observe that it is super leet.
Overall, this patch has the effect of killing some code (no more hackish
int-to-double conversions in ArithMod), making some optimization work on
more platforms, and making the compiler less confusing by doing more things
with the same idiom.
* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(DFG):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileArithMod):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
LayoutTests:
Reviewed by Mark Hahnenberg.
* fast/js/script-tests/integer-division-neg2tothe32-by-neg1.js:
(myModBy2):
(myModBy1073741824):
Canonical link: https://commits.webkit.org/136970@main
git-svn-id: https://svn.webkit.org/repository/webkit/trunk@153186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-07-25 04:01:11 +00:00
|
|
|
PASS myModBy2(x) is -0
|
|
|
|
|
PASS myModBy1073741824(x) is -0
|
|
|
|
|
PASS myModBy2(y) is -1
|
|
|
|
|
PASS myModBy1073741824(y) is -1
|
|
|
|
|
PASS myModBy2(z) is 1
|
|
|
|
|
PASS myModBy1073741824(z) is 3
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS myModNeg2ToThe31(y) is -0
|
|
|
|
|
PASS myOtherDiv(w, v) is 2147483648
|
|
|
|
|
PASS myOtherDivByNeg1(w) is 2147483648
|
|
|
|
|
PASS myOtherDivNeg2ToThe31(v) is 2147483648
|
|
|
|
|
PASS myOtherMod(w, v) is -0
|
|
|
|
|
PASS myOtherModByNeg1(w) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(v) is -0
|
|
|
|
|
PASS myOtherModNeg2ToThe31(3) is -2
|
2013-01-16 05:47:09 +00:00
|
|
|
PASS myDivExpectingInt(x, y) is x
|
2012-03-21 01:29:28 +00:00
|
|
|
PASS successfullyParsed is true
|
|
|
|
|
|
|
|
|
|
TEST COMPLETE
|
|
|
|
|
|