haikuwebkit/LayoutTests/js/dfg-arith-add-overflow-chec...

10 lines
344 B
Plaintext
Raw Permalink Normal View History

DFG overflow check elimination is too smart for its own good https://bugs.webkit.org/show_bug.cgi?id=111832 Source/JavaScriptCore: Reviewed by Oliver Hunt and Gavin Barraclough. Rolling this back in after fixing accidental misuse of JSValue. The code was doing value < someInt rather than value.asInt32() < someInt. This "worked" when isWithinPowerOfTwo wasn't templatized. It worked by always being false and always disabling the relvant optimization. This improves overflow check elimination in three ways: 1) It reduces the amount of time the compiler will spend doing it. 2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children) are int32's and then perform a possibly-overflowing operation, we must be careful not to assume that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that @b->children are int32's and that hence @b might produce a large enough result that doubles would start chopping low bits. The specific implication of this is that for a binary operation to not propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that large won't even make it into the DFG currently. 3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate NodeUsedAsNumber to either @a or @b. This is neutral on V8v7 and a slight speed-up on compile time benchmarks. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * dfg/DFGBackwardsPropagationPhase.cpp: Added. (DFG): (BackwardsPropagationPhase): (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase): (JSC::DFG::BackwardsPropagationPhase::run): (JSC::DFG::BackwardsPropagationPhase::isNotNegZero): (JSC::DFG::BackwardsPropagationPhase::isNotZero): (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant): (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive): (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags): (JSC::DFG::BackwardsPropagationPhase::propagate): (JSC::DFG::performBackwardsPropagation): * dfg/DFGBackwardsPropagationPhase.h: Added. (DFG): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::run): (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom): (CPSRethreadingPhase): (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): (DFG): * dfg/DFGNodeFlags.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (PredictionPropagationPhase): (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGUnificationPhase.cpp: (JSC::DFG::UnificationPhase::run): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::mergeIsLoadedFrom): (VariableAccessData): (JSC::DFG::VariableAccessData::setIsLoadedFrom): (JSC::DFG::VariableAccessData::isLoadedFrom): LayoutTests: Reviewed by Oliver Hunt and Gavin Barraclough. * fast/js/dfg-arith-add-overflow-check-elimination-predicted-but-not-proven-int-expected.txt: Added. * fast/js/dfg-arith-add-overflow-check-elimination-predicted-but-not-proven-int.html: Added. * fast/js/dfg-arith-add-overflow-check-elimination-tower-of-large-numbers-expected.txt: Added. * fast/js/dfg-arith-add-overflow-check-elimination-tower-of-large-numbers.html: Added. * fast/js/jsc-test-list: * fast/js/script-tests/dfg-arith-add-overflow-check-elimination-predicted-but-not-proven-int.js: Added. (foo): (bar): * fast/js/script-tests/dfg-arith-add-overflow-check-elimination-tower-of-large-numbers.js: Added. (foo): (bar): Canonical link: https://commits.webkit.org/130423@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@145489 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-03-12 06:43:54 +00:00
Tests that if we have a tower of large numerical constants being added to each other, the DFG knows that a sufficiently large tower may produce a large enough value that overflow check elimination must be careful.
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
Passed some tests silently.
DFG overflow check elimination is too smart for its own good https://bugs.webkit.org/show_bug.cgi?id=111832 Source/JavaScriptCore: Reviewed by Oliver Hunt and Gavin Barraclough. Rolling this back in after fixing accidental misuse of JSValue. The code was doing value < someInt rather than value.asInt32() < someInt. This "worked" when isWithinPowerOfTwo wasn't templatized. It worked by always being false and always disabling the relvant optimization. This improves overflow check elimination in three ways: 1) It reduces the amount of time the compiler will spend doing it. 2) It fixes bugs where overflow check elimination was overzealous. Precisely, for a binary operation over @a and @b where both @a and @b will type check that their inputs (@a->children, @b->children) are int32's and then perform a possibly-overflowing operation, we must be careful not to assume that @a's non-int32 parts don't matter if at the point that @a runs we have as yet not proved that @b->children are int32's and that hence @b might produce a large enough result that doubles would start chopping low bits. The specific implication of this is that for a binary operation to not propagate that it cares about non-int32 parts (NodeUsedAsNumber), we must prove that at least one of the inputs is guaranteed to produce a result within 2^32 and that there won't be a tower of such operations large enough to ultimately produce a double greater than 2^52 (roughly). We achieve the latter by disabling this optimization for very large basic blocks. It's noteworthy that blocks that large won't even make it into the DFG currently. 3) It makes the overflow check elimination more precise for cases where the inputs to an Add or Sub are the outputs of a bit-op. For example in (@a + (@b | 0)) | 0, we don't need to propagate NodeUsedAsNumber to either @a or @b. This is neutral on V8v7 and a slight speed-up on compile time benchmarks. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * Target.pri: * dfg/DFGArrayMode.cpp: (JSC::DFG::ArrayMode::refine): * dfg/DFGBackwardsPropagationPhase.cpp: Added. (DFG): (BackwardsPropagationPhase): (JSC::DFG::BackwardsPropagationPhase::BackwardsPropagationPhase): (JSC::DFG::BackwardsPropagationPhase::run): (JSC::DFG::BackwardsPropagationPhase::isNotNegZero): (JSC::DFG::BackwardsPropagationPhase::isNotZero): (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoForConstant): (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwoNonRecursive): (JSC::DFG::BackwardsPropagationPhase::isWithinPowerOfTwo): (JSC::DFG::BackwardsPropagationPhase::mergeDefaultFlags): (JSC::DFG::BackwardsPropagationPhase::propagate): (JSC::DFG::performBackwardsPropagation): * dfg/DFGBackwardsPropagationPhase.h: Added. (DFG): * dfg/DFGCPSRethreadingPhase.cpp: (JSC::DFG::CPSRethreadingPhase::run): (JSC::DFG::CPSRethreadingPhase::clearIsLoadedFrom): (CPSRethreadingPhase): (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor): (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor): * dfg/DFGDriver.cpp: (JSC::DFG::compile): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::dump): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): (DFG): * dfg/DFGNodeFlags.h: (DFG): * dfg/DFGPredictionPropagationPhase.cpp: (PredictionPropagationPhase): (JSC::DFG::PredictionPropagationPhase::propagate): * dfg/DFGUnificationPhase.cpp: (JSC::DFG::UnificationPhase::run): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::VariableAccessData): (JSC::DFG::VariableAccessData::mergeIsLoadedFrom): (VariableAccessData): (JSC::DFG::VariableAccessData::setIsLoadedFrom): (JSC::DFG::VariableAccessData::isLoadedFrom): LayoutTests: Reviewed by Oliver Hunt and Gavin Barraclough. * fast/js/dfg-arith-add-overflow-check-elimination-predicted-but-not-proven-int-expected.txt: Added. * fast/js/dfg-arith-add-overflow-check-elimination-predicted-but-not-proven-int.html: Added. * fast/js/dfg-arith-add-overflow-check-elimination-tower-of-large-numbers-expected.txt: Added. * fast/js/dfg-arith-add-overflow-check-elimination-tower-of-large-numbers.html: Added. * fast/js/jsc-test-list: * fast/js/script-tests/dfg-arith-add-overflow-check-elimination-predicted-but-not-proven-int.js: Added. (foo): (bar): * fast/js/script-tests/dfg-arith-add-overflow-check-elimination-tower-of-large-numbers.js: Added. (foo): (bar): Canonical link: https://commits.webkit.org/130423@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@145489 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2013-03-12 06:43:54 +00:00
TEST COMPLETE