[webkit-changes] [291075] trunk/Source/WebGPU
Title: [291075] trunk/Source/WebGPU Revision 291075 Author rmoris...@apple.com Date 2022-03-09 14:25:11 -0800 (Wed, 09 Mar 2022) Log Message [WGSL] Implement enough of the Parser for the simplest shaders https://bugs.webkit.org/show_bug.cgi?id=237629 Reviewed by Myles Maxfield. The specific "hello-world"-like shaders that I want this to be able to parse are included in WGSLParserTests.mm. The general approach to the parser, such as its templating by the Lexer, is directly copied from JSC's parser. Things are a bit simpler for us as WGSL is such a simple language to parse, being strictly LR(1). In this patch I also deleted BlockAttribute, since this attribute was recently removed from the language. * WGSL/AST/Attribute.h: (WGSL::AST::Attribute::isBlock const): Deleted. * WGSL/AST/Expressions/TypeConversion.h: * WGSL/AST/FunctionDecl.h: * WGSL/AST/ShaderModule.h: * WGSL/AST/Statements/AssignmentStatement.h: * WGSL/AST/StructureDecl.h: * WGSL/AST/TypeDecl.h: (WGSL::AST::ParameterizedType::stringViewToKind): * WGSL/CompilationMessage.h: * WGSL/Parser.cpp: Added. (WGSL::Parser::Parser): (WGSL::Parser::current): (WGSL::parse): (WGSL::parseLChar): (WGSL::parseUChar): (WGSL::Parser::consumeType): (WGSL::Parser::consume): (WGSL::Parser::parseShader): (WGSL::Parser::parseGlobalDecl): (WGSL::Parser::parseAttributes): (WGSL::Parser::parseAttribute): (WGSL::Parser::parseStructDecl): (WGSL::Parser::parseStructMember): (WGSL::Parser::parseTypeDecl): (WGSL::Parser::parseTypeDeclAfterIdentifier): (WGSL::Parser::parseGlobalVariableDecl): (WGSL::Parser::parseVariableQualifier): (WGSL::Parser::parseStorageClass): (WGSL::Parser::parseAccessMode): (WGSL::Parser::parseFunctionDecl): (WGSL::Parser::parseParameter): (WGSL::Parser::parseStatement): (WGSL::Parser::parseCompoundStatement): (WGSL::Parser::parseReturnStatement): (WGSL::Parser::parseShortCircuitOrExpression): (WGSL::Parser::parseRelationalExpression): (WGSL::Parser::parseShiftExpression): (WGSL::Parser::parseAdditiveExpression): (WGSL::Parser::parseMultiplicativeExpression): (WGSL::Parser::parseUnaryExpression): (WGSL::Parser::parseSingularExpression): (WGSL::Parser::parsePostfixExpression): (WGSL::Parser::parsePrimaryExpression): (WGSL::Parser::parseExpression): (WGSL::Parser::parseLHSExpression): (WGSL::Parser::parseCoreLHSExpression): (WGSL::Parser::parseArgumentExpressionList): * WGSL/Parser.h: Copied from Source/WebGPU/WGSL/CompilationMessage.h. * WGSL/WGSL.cpp: (WGSL::staticCheck): (WGSL::SuccessfulCheck::SuccessfulCheck): * WGSL/WGSL.h: * WebGPU.xcodeproj/project.pbxproj: Modified Paths trunk/Source/WebGPU/ChangeLog trunk/Source/WebGPU/WGSL/AST/Attribute.h trunk/Source/WebGPU/WGSL/AST/Expressions/TypeConversion.h trunk/Source/WebGPU/WGSL/AST/FunctionDecl.h trunk/Source/WebGPU/WGSL/AST/ShaderModule.h trunk/Source/WebGPU/WGSL/AST/Statements/AssignmentStatement.h trunk/Source/WebGPU/WGSL/AST/StructureDecl.h trunk/Source/WebGPU/WGSL/AST/TypeDecl.h trunk/Source/WebGPU/WGSL/CompilationMessage.h trunk/Source/WebGPU/WGSL/WGSL.cpp trunk/Source/WebGPU/WGSL/WGSL.h trunk/Source/WebGPU/WebGPU.xcodeproj/project.pbxproj Added Paths trunk/Source/WebGPU/WGSL/Parser.cpp trunk/Source/WebGPU/WGSL/Parser.h trunk/Source/WebGPU/WGSLUnitTests/WGSLParserTests.mm Diff Modified: trunk/Source/WebGPU/ChangeLog (291074 => 291075) --- trunk/Source/WebGPU/ChangeLog 2022-03-09 22:16:38 UTC (rev 291074) +++ trunk/Source/WebGPU/ChangeLog 2022-03-09 22:25:11 UTC (rev 291075) @@ -1,3 +1,72 @@ +2022-03-09 Robin Morisset + +[WGSL] Implement enough of the Parser for the simplest shaders +https://bugs.webkit.org/show_bug.cgi?id=237629 + +Reviewed by Myles Maxfield. + +The specific "hello-world"-like shaders that I want this to be able to parse are included in WGSLParserTests.mm. + +The general approach to the parser, such as its templating by the Lexer, is directly copied from JSC's parser. +Things are a bit simpler for us as WGSL is such a simple language to parse, being strictly LR(1). + +In this patch I also deleted BlockAttribute, since this attribute was recently removed from the language. + +* WGSL/AST/Attribute.h: +(WGSL::AST::Attribute::isBlock const): Deleted. +* WGSL/AST/Expressions/TypeConversion.h: +* WGSL/AST/FunctionDecl.h: +* WGSL/AST/ShaderModule.h: +* WGSL/AST/Statements/AssignmentStatement.h: +* WGSL/AST/StructureDecl.h: +* WGSL/AST/TypeDecl.h: +(WGSL::AST::ParameterizedType::stringViewToKind): +* WGSL/CompilationMessage.h: +* WGSL/Parser.cpp: Added. +(WGSL::Parser::Parser): +(WGSL::Parser::current): +(WGSL::parse): +(WGSL::parseLChar): +(WGSL::parseUChar): +(WGSL::Parser::consumeType): +(WGSL::Parser::consume): +(WGSL::Parser::parseShader): +(WGSL::Parser::parseGlobalDecl): +(WGSL::Parser::parseAttributes): +
[webkit-changes] [291027] trunk/Source
Title: [291027] trunk/Source Revision 291027 Author rmoris...@apple.com Date 2022-03-08 18:56:37 -0800 (Tue, 08 Mar 2022) Log Message [WTF] LikelyDenseUnsignedIntegerSet::add can cause a reindexing of the entire bit vector with every call in the worst case https://bugs.webkit.org/show_bug.cgi?id=236997 Reviewed by Saam Barati. Source/_javascript_Core: Just make it a little bit easier to change the number of stack slots in testZDefOfSpillSlotWithOffsetNeedingToBeMaterializedInARegister. * b3/air/testair.cpp: Source/WTF: This problem was found while investigating https://bugs.webkit.org/show_bug.cgi?id=236269. LikelyDenseUnsignedIntegerSet has two forms: either as a HashSet (if sparse) or as a BitVector representing numbers above some value m_min (if sufficiently dense). This is a massive memory win in most situations (>4x in practice for register allocation in JS2, >20x on some pathological webpages). But it means that when adding a value below m_min to a set in BitVector shape, we have to rebuild the whole set, which takes a time proportional to the time of the set. So if building a set by repeatedly adding decreasing values (like in https://bugs.webkit.org/show_bug.cgi?id=236269 where we add 1, then , then 9998, etc..), we have some awful performance. In this patch I improve this situation in two ways: - First I always round down m_min to the next multiple of 64. This means that when adding contiguous values like above we only re-index once every 64 adds. - It then allows me to do the reindexing by simple memcpy instead of costly iteration of all the set bits, since they are now always at the same offset within the words of the BitVector. On an M1 MBP, on testair:: testZDefOfSpillSlotWithOffsetNeedingToBeMaterializedInARegister, with n=5000, in release mode, measuring just the time spent building the interference graph: Before this patch: 107 s After this patch: 77 ms (note the different unit, it is not a typo!) Unfortunately, it does not seem to significantly improve the time spent in LikelyDenseUnsignedIntgerSet::add in JetStream2, probably because the pattern of always adding a value just before the minimum is quite pathological/rare. I still think it is worth landing, as we don't know what code out there may hit this performance problem. * wtf/BitVector.cpp: (WTF::BitVector::shiftRightByMultipleOf64): (WTF::BitVector::resizeOutOfLine): * wtf/BitVector.h: * wtf/LikelyDenseUnsignedIntegerSet.h: (WTF::LikelyDenseUnsignedIntegerSet::add): (WTF::LikelyDenseUnsignedIntegerSet::validate const): (WTF::LikelyDenseUnsignedIntegerSet::transitionToBitVector): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/air/testair.cpp trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/BitVector.cpp trunk/Source/WTF/wtf/BitVector.h trunk/Source/WTF/wtf/LikelyDenseUnsignedIntegerSet.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (291026 => 291027) --- trunk/Source/_javascript_Core/ChangeLog 2022-03-09 02:53:09 UTC (rev 291026) +++ trunk/Source/_javascript_Core/ChangeLog 2022-03-09 02:56:37 UTC (rev 291027) @@ -1,3 +1,14 @@ +2022-03-08 Robin Morisset + +[WTF] LikelyDenseUnsignedIntegerSet::add can cause a reindexing of the entire bit vector with every call in the worst case +https://bugs.webkit.org/show_bug.cgi?id=236997 + +Reviewed by Saam Barati. + +Just make it a little bit easier to change the number of stack slots in testZDefOfSpillSlotWithOffsetNeedingToBeMaterializedInARegister. + +* b3/air/testair.cpp: + 2022-03-08 Robin Morisset Enable tier-up in loops created by recursive tail call optimizations. Modified: trunk/Source/_javascript_Core/b3/air/testair.cpp (291026 => 291027) --- trunk/Source/_javascript_Core/b3/air/testair.cpp 2022-03-09 02:53:09 UTC (rev 291026) +++ trunk/Source/_javascript_Core/b3/air/testair.cpp 2022-03-09 02:56:37 UTC (rev 291027) @@ -2371,7 +2371,8 @@ BasicBlock* root = code.addBlock(); Vector slots; -for (unsigned i = 0; i < 1; ++i) +unsigned numberOfSlots = 1; +for (unsigned i = 0; i < numberOfSlots; ++i) slots.append(code.addStackSlot(8, StackSlotKind::Spill)); for (auto* slot : slots) @@ -2388,7 +2389,7 @@ root->append(Ret64, nullptr, Tmp(GPRInfo::returnValueGPR)); int32_t result = compileAndRun(proc, 1); -CHECK(result == 1); +CHECK(result == static_cast(numberOfSlots)); } #define PREFIX "O", Options::defaultB3OptLevel(), ": " Modified: trunk/Source/WTF/ChangeLog (291026 => 291027) --- trunk/Source/WTF/ChangeLog 2022-03-09 02:53:09 UTC (rev 291026) +++ trunk/Source/WTF/ChangeLog 2022-03-09 02:56:37 UTC (rev 291027) @@ -1,3 +1,38 @@ +2022-03-08 Robin Morisset + +[WTF] LikelyDenseUnsignedIntegerSet::add can cause a reindexing of the entire bit vector with every call in the worst case +https://bugs.webkit.org/show_bug.cgi?id=236997 + +Reviewed by
[webkit-changes] [291026] trunk
Title: [291026] trunk
Revision 291026
Author rmoris...@apple.com
Date 2022-03-08 18:53:09 -0800 (Tue, 08 Mar 2022)
Log Message
Enable tier-up in loops created by recursive tail call optimizations.
https://bugs.webkit.org/show_bug.cgi?id=178389
Reviewed by Saam Barati.
PerformanceTests:
Just changed a constant for consistency with TailBench9000/merge-sort.js
* TailBench9000/merge-sort-cps.js:
Source/_javascript_Core:
Made the recursive tail call optimization only run in FTL mode, since it is a significant progression on TailBench.
Also some trivial refactoring of handleRecursiveTailCall.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
Modified Paths
trunk/PerformanceTests/ChangeLog
trunk/PerformanceTests/TailBench9000/merge-sort-cps.js
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp
Diff
Modified: trunk/PerformanceTests/ChangeLog (291025 => 291026)
--- trunk/PerformanceTests/ChangeLog 2022-03-09 02:25:17 UTC (rev 291025)
+++ trunk/PerformanceTests/ChangeLog 2022-03-09 02:53:09 UTC (rev 291026)
@@ -1,3 +1,14 @@
+2022-03-08 Robin Morisset
+
+Enable tier-up in loops created by recursive tail call optimizations.
+https://bugs.webkit.org/show_bug.cgi?id=178389
+
+Reviewed by Saam Barati.
+
+Just changed a constant for consistency with TailBench9000/merge-sort.js
+
+* TailBench9000/merge-sort-cps.js:
+
2022-03-01 Yusuke Suzuki
Fix Speedometer's setTimeout throttling issue
Modified: trunk/PerformanceTests/TailBench9000/merge-sort-cps.js (291025 => 291026)
--- trunk/PerformanceTests/TailBench9000/merge-sort-cps.js 2022-03-09 02:25:17 UTC (rev 291025)
+++ trunk/PerformanceTests/TailBench9000/merge-sort-cps.js 2022-03-09 02:53:09 UTC (rev 291026)
@@ -131,7 +131,7 @@
let arrays = [
buildArray(10, x => x),
buildArray(10, x => -x),
-buildArray(1000, x => random())
+buildArray(1, x => random())
];
function test(index)
Modified: trunk/Source/_javascript_Core/ChangeLog (291025 => 291026)
--- trunk/Source/_javascript_Core/ChangeLog 2022-03-09 02:25:17 UTC (rev 291025)
+++ trunk/Source/_javascript_Core/ChangeLog 2022-03-09 02:53:09 UTC (rev 291026)
@@ -1,3 +1,16 @@
+2022-03-08 Robin Morisset
+
+Enable tier-up in loops created by recursive tail call optimizations.
+https://bugs.webkit.org/show_bug.cgi?id=178389
+
+Reviewed by Saam Barati.
+
+Made the recursive tail call optimization only run in FTL mode, since it is a significant progression on TailBench.
+Also some trivial refactoring of handleRecursiveTailCall.
+
+* dfg/DFGByteCodeParser.cpp:
+(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
+
2022-03-08 Saam Barati
[JSC] Enable ThinLTO
Modified: trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp (291025 => 291026)
--- trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp 2022-03-09 02:25:17 UTC (rev 291025)
+++ trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp 2022-03-09 02:53:09 UTC (rev 291026)
@@ -1467,6 +1467,11 @@
if (UNLIKELY(!Options::optimizeRecursiveTailCalls()))
return false;
+// This optimisation brings more performance if it only runs in FTL, probably because it interferes with tier-up.
+// See https://bugs.webkit.org/show_bug.cgi?id=178389 for details.
+if (!isFTL(m_graph.m_plan.mode()))
+return false;
+
auto targetExecutable = callVariant.executable();
InlineStackEntry* stackEntry = m_inlineStackTop;
do {
@@ -1488,6 +1493,10 @@
// a good target to jump into.
if (callFrame->isVarargs())
continue;
+// If an InlineCallFrame is not a closure, it was optimized using a constant callee.
+// Check if this is the same callee that we are dealing with.
+if (!callFrame->isClosureCall && callFrame->calleeConstant() != callVariant.function())
+continue;
} else {
// We are in the machine code entry (i.e. the original caller).
// If we have more arguments than the number of parameters to the function, it is not clear where we could put them on the stack.
@@ -1495,13 +1504,6 @@
return false;
}
-// If an InlineCallFrame is not a closure, it was optimized using a constant callee.
-// Check if this is the same callee that we try to inline here.
-if (stackEntry->m_inlineCallFrame && !stackEntry->m_inlineCallFrame->isClosureCall) {
-if (stackEntry->m_inlineCallFrame->calleeConstant() != callVariant.function())
-continue;
-}
-
// We must add some check that the profiling information was correct and the target of this call is what we thought.
emitFunctionCheckIfNeeded();
// We flush everything, as if we were in the backedge of a loop (see treatment of
[webkit-changes] [291005] trunk/Source/WebGPU
Title: [291005] trunk/Source/WebGPU Revision 291005 Author rmoris...@apple.com Date 2022-03-08 12:41:12 -0800 (Tue, 08 Mar 2022) Log Message [WGSL] Add enough of the AST for the simplest shaders https://bugs.webkit.org/show_bug.cgi?id=236655 Reviewed by Myles Maxfield. These AST nodes are just those required for the most trivial graphics and compute shaders. I used the machinery from wtf/TypeCasts as suggested by Myles in https://bugs.webkit.org/show_bug.cgi?id=233276. Currently all of the code for these nodes is included in WGSL.cpp to verify that they build. This will be removed in the parser patch. Attributes are added in setAttributes methods instead of being part of the constructors, because it can fail, and returning an error from a constructor is tricky. * WGSL/AST/Attribute.h: Added. (WGSL::AST::Attribute::Attribute): (WGSL::AST::Attribute::kind const): (WGSL::AST::Attribute::isBlock const): (WGSL::AST::Attribute::isGroup const): (WGSL::AST::Attribute::isBinding const): (WGSL::AST::Attribute::isStage const): (WGSL::AST::Attribute::isLocation const): (WGSL::AST::Attribute::isBuiltin const): (WGSL::AST::BlockAttribute::BlockAttribute): (WGSL::AST::GroupAttribute::GroupAttribute): (WGSL::AST::GroupAttribute::group const): (WGSL::AST::BindingAttribute::BindingAttribute): (WGSL::AST::BindingAttribute::binding const): (WGSL::AST::StageAttribute::StageAttribute): (WGSL::AST::StageAttribute::stage const): (WGSL::AST::BuiltinAttribute::BuiltinAttribute): (WGSL::AST::BuiltinAttribute::name const): (WGSL::AST::LocationAttribute::LocationAttribute): (WGSL::AST::LocationAttribute::location const): * WGSL/AST/_expression_.h: Added. (WGSL::AST::_expression_::_expression_): (WGSL::AST::_expression_::kind const): (WGSL::AST::_expression_::isBoolLiteral const): (WGSL::AST::_expression_::isInt32Literal const): (WGSL::AST::_expression_::isUInt32Literal const): (WGSL::AST::_expression_::isFloat32Literal const): (WGSL::AST::_expression_::isIdentifier const): (WGSL::AST::_expression_::isStructureAccess const): (WGSL::AST::_expression_::isTypeConversion const): * WGSL/AST/Expressions/IdentifierExpression.h: Added. (WGSL::AST::IdentifierExpression::IdentifierExpression): (WGSL::AST::IdentifierExpression::identifier const): * WGSL/AST/Expressions/LiteralExpressions.h: Added. (WGSL::AST::BoolLiteral::BoolLiteral): (WGSL::AST::BoolLiteral::value const): (WGSL::AST::Int32Literal::Int32Literal): (WGSL::AST::Int32Literal::value const): (WGSL::AST::Uint32Literal::Uint32Literal): (WGSL::AST::Uint32Literal::value const): (WGSL::AST::Float32Literal::Float32Literal): (WGSL::AST::Float32Literal::value const): * WGSL/AST/Expressions/StructureAccess.h: Added. (WGSL::AST::StructureAccess::StructureAccess): (WGSL::AST::StructureAccess::base): (WGSL::AST::StructureAccess::fieldName const): * WGSL/AST/Expressions/TypeConversion.h: Added. (WGSL::AST::TypeConversion::TypeConversion): (WGSL::AST::TypeConversion::typeDecl): (WGSL::AST::TypeConversion::arguments): * WGSL/AST/FunctionDecl.h: Added. (WGSL::AST::Parameter::Parameter): (WGSL::AST::Parameter::setAttributes): (WGSL::AST::Parameter::builtin const): (WGSL::AST::Parameter::location const): (WGSL::AST::Parameter::name const): (WGSL::AST::Parameter::type): (WGSL::AST::FunctionDecl::FunctionDecl): (WGSL::AST::FunctionDecl::setAttributes): (WGSL::AST::FunctionDecl::setReturnAttributes): (WGSL::AST::FunctionDecl::entryPointStage const): (WGSL::AST::FunctionDecl::name const): (WGSL::AST::FunctionDecl::parameters): (WGSL::AST::FunctionDecl::returnBuiltin const): (WGSL::AST::FunctionDecl::returnLocation const): (WGSL::AST::FunctionDecl::maybeReturnType): (WGSL::AST::FunctionDecl::body): * WGSL/AST/GlobalDecl.h: Added. (WGSL::AST::GlobalDecl::GlobalDecl): (WGSL::AST::GlobalDecl::kind const): (WGSL::AST::GlobalDecl::isGlobalVariable const): (WGSL::AST::GlobalDecl::isStruct const): (WGSL::AST::GlobalDecl::isFunction const): * WGSL/AST/GlobalDirective.h: Added. (WGSL::AST::GlobalDirective::name const): * WGSL/AST/GlobalVariableDecl.h: Added. (WGSL::AST::GlobalVariableDecl::GlobalVariableDecl): (WGSL::AST::GlobalVariableDecl::setAttributes): (WGSL::AST::GlobalVariableDecl::group const): (WGSL::AST::GlobalVariableDecl::binding const): (WGSL::AST::GlobalVariableDecl::name const): (WGSL::AST::GlobalVariableDecl::maybeQualifier): (WGSL::AST::GlobalVariableDecl::maybeTypeDecl): (WGSL::AST::GlobalVariableDecl::maybeInitializer): * WGSL/AST/Shader.h: Renamed from Source/WebGPU/WGSL/AST.h. * WGSL/AST/Statement.h: Added. (WGSL::AST::Statement::Statement): (WGSL::AST::Statement::kind const): (WGSL::AST::Statement::isCompound const): (WGSL::AST::Statement::isReturn const): (WGSL::AST::Statement::isAssignment const): * WGSL/AST/Statements/AssignmentStatement.h: Added. (WGSL::AST::AssignmentStatement::AssignmentStatement): (WGSL::AST::AssignmentStatement::maybeLhs): (WGSL::AST::AssignmentStatement::rhs): * WGSL/AST/Statements/ReturnStatement.h: Added. (WGSL::AST::ReturnStatement::ReturnStatement):
[webkit-changes] [291004] trunk/Source/WebGPU
Title: [291004] trunk/Source/WebGPU
Revision 291004
Author rmoris...@apple.com
Date 2022-03-08 12:15:09 -0800 (Tue, 08 Mar 2022)
Log Message
[WGSL] The lexer should use the functions from wtf/ASCIICType.h
https://bugs.webkit.org/show_bug.cgi?id=236783
Reviewed by Darin Adler.
I was not aware of these functions when I wrote the lexer, and I ended up reimplementing them.
Reusing them is both simpler, and slightly more efficient as some of them (especially isASCIISpace) have been optimized.
* WGSL/Lexer.cpp:
(WGSL::Lexer::lex):
(WGSL::Lexer::skipWhitespace):
(WGSL::Lexer::parseDecimalInteger):
(WGSL::Lexer::parseDecimalFloatExponent):
(WGSL::Lexer::isWhiteSpace): Deleted.
(WGSL::Lexer::isIdentifierStart): Deleted.
(WGSL::Lexer::isValidIdentifierCharacter): Deleted.
(WGSL::Lexer::isDecimal): Deleted.
(WGSL::Lexer::isHexadecimal): Deleted.
(WGSL::Lexer::readDecimal): Deleted.
(WGSL::Lexer::readHexadecimal): Deleted.
* WGSL/Lexer.h:
Modified Paths
trunk/Source/WebGPU/ChangeLog
trunk/Source/WebGPU/WGSL/Lexer.cpp
trunk/Source/WebGPU/WGSL/Lexer.h
Diff
Modified: trunk/Source/WebGPU/ChangeLog (291003 => 291004)
--- trunk/Source/WebGPU/ChangeLog 2022-03-08 20:05:36 UTC (rev 291003)
+++ trunk/Source/WebGPU/ChangeLog 2022-03-08 20:15:09 UTC (rev 291004)
@@ -1,3 +1,27 @@
+2022-03-08 Robin Morisset
+
+[WGSL] The lexer should use the functions from wtf/ASCIICType.h
+https://bugs.webkit.org/show_bug.cgi?id=236783
+
+Reviewed by Darin Adler.
+
+I was not aware of these functions when I wrote the lexer, and I ended up reimplementing them.
+Reusing them is both simpler, and slightly more efficient as some of them (especially isASCIISpace) have been optimized.
+
+* WGSL/Lexer.cpp:
+(WGSL::Lexer::lex):
+(WGSL::Lexer::skipWhitespace):
+(WGSL::Lexer::parseDecimalInteger):
+(WGSL::Lexer::parseDecimalFloatExponent):
+(WGSL::Lexer::isWhiteSpace): Deleted.
+(WGSL::Lexer::isIdentifierStart): Deleted.
+(WGSL::Lexer::isValidIdentifierCharacter): Deleted.
+(WGSL::Lexer::isDecimal): Deleted.
+(WGSL::Lexer::isHexadecimal): Deleted.
+(WGSL::Lexer::readDecimal): Deleted.
+(WGSL::Lexer::readHexadecimal): Deleted.
+* WGSL/Lexer.h:
+
2022-03-07 Michael Saboff
Catalyst build failure in WebGPU when building with SYSTEM_CONTENT_PATH
Modified: trunk/Source/WebGPU/WGSL/Lexer.cpp (291003 => 291004)
--- trunk/Source/WebGPU/WGSL/Lexer.cpp 2022-03-08 20:05:36 UTC (rev 291003)
+++ trunk/Source/WebGPU/WGSL/Lexer.cpp 2022-03-08 20:15:09 UTC (rev 291004)
@@ -110,9 +110,9 @@
// FIXME: add support for hexadecimal floating point literals
shift();
bool hexNumberIsEmpty = true;
-while (isHexadecimal(m_current)) {
+while (isASCIIHexDigit(m_current)) {
literalValue *= 16;
-literalValue += readHexadecimal(m_current);
+literalValue += toASCIIHexValue(m_current);
shift();
hexNumberIsEmpty = false;
}
@@ -122,7 +122,7 @@
}
bool isFloatingPoint = false;
-if (isDecimal(m_current) || m_current == '.' || m_current == 'e' || m_current == 'E') {
+if (isASCIIDigit(m_current) || m_current == '.' || m_current == 'e' || m_current == 'E') {
std::optional integerPart = parseDecimalInteger();
if (integerPart)
literalValue = integerPart.value();
@@ -159,7 +159,7 @@
return parseIntegerLiteralSuffix(literalValue);
}
default:
-if (isDecimal (m_current)) {
+if (isASCIIDigit(m_current)) {
std::optional value = parseDecimalInteger();
if (!value)
return makeToken(TokenType::Invalid);
@@ -267,7 +267,7 @@
template
void Lexer::skipWhitespace()
{
-while (isWhiteSpace(m_current)) {
+while (isASCIISpace(m_current)) {
if (m_current == '\n') {
shift();
++m_currentPosition.m_line;
@@ -291,11 +291,11 @@
template
std::optional Lexer::parseDecimalInteger()
{
-if (!isDecimal(m_current))
+if (!isASCIIDigit(m_current))
return std::nullopt;
CheckedUint64 value = 0;
-while (isDecimal(m_current)) {
+while (isASCIIDigit(m_current)) {
value *= 10ull;
value += readDecimal(m_current);
shift();
@@ -315,9 +315,9 @@
if (m_current != 'e' && m_current != 'E')
return std::nullopt;
if (char1 == '+' || char1 == '-') {
-if (!isDecimal(char2))
+if (!isASCIIDigit(char2))
return std::nullopt;
-} else if (!isDecimal(char1))
+} else if (!isASCIIDigit(char1))
return std::nullopt;
shift();
@@ -353,65 +353,6 @@
return makeLiteralToken(TokenType::IntegerLiteral, literalValue);
};
-template
-ALWAYS_INLINE bool Lexer::isWhiteSpace(T ch)
-{
-switch
[webkit-changes] [290290] trunk/Source
Title: [290290] trunk/Source Revision 290290 Author rmoris...@apple.com Date 2022-02-21 22:53:58 -0800 (Mon, 21 Feb 2022) Log Message [JSC] Format the output of --reportTotalPhaseTimes=1 more nicely https://bugs.webkit.org/show_bug.cgi?id=237005 Reviewed by Saam Barati. Source/_javascript_Core: Before this patch: [B3] moveConstants total ms: 64.307583 max ms: 1.703167 [B3] lowerToAir total ms: 151.297782 max ms: 5.426375 [B3] generateToAir total ms: 1623.987166 max ms: 92.826750 [B3] simplifyCFG total ms: 11.760463 max ms: 1.088083 [B3] Air::lowerMacros total ms: 5.975679 max ms: 0.382000 After this patch: total ms: 66.328 max ms: 2.283 [B3] moveConstants total ms: 148.097 max ms: 5.361 [B3] lowerToAir total ms: 1619.115 max ms: 96.307 [Total B3] generateToAir total ms: 11.959 max ms: 1.185 [Air] simplifyCFG total ms:6.519 max ms: 0.697 [Air] Air::lowerMacros Concretely there are two changes: - use FixedWidthDouble (also introduced to WTF in this patch) to line-up the total times. This makes it possible to see at a glance which phases are worth optimizing and which aren't. - Tag phases more precisely, and in particular replace [B3] by [Air] where relevant, and give different tags to measurements that correspond to groups of phases instead of a single phase (e.g. generateToAir). * _javascript_Core.xcodeproj/project.pbxproj: * b3/B3Compile.cpp: (JSC::B3::compile): * b3/B3FixSSA.cpp: * b3/B3Generate.cpp: (JSC::B3::prepareForGeneration): (JSC::B3::generateToAir): * b3/B3PhaseScope.cpp: (JSC::B3::PhaseScope::PhaseScope): * b3/B3PhaseScope.h: * b3/B3TimingScope.h: Removed. (JSC::B3::TimingScope::TimingScope): Deleted. * b3/B3VariableLiveness.cpp: (JSC::B3::VariableLiveness::VariableLiveness): * b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::generate): * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: * b3/air/AirGenerate.cpp: (JSC::B3::Air::prepareForGeneration): (JSC::B3::Air::generateWithAlreadyAllocatedRegisters): * b3/air/AirLiveness.h: (JSC::B3::Air::Liveness::Liveness): * b3/air/AirPhaseScope.cpp: (JSC::B3::Air::PhaseScope::PhaseScope): * b3/air/AirPhaseScope.h: * tools/CompilerTimingScope.cpp: Source/WTF: Add FixedWidthDouble, which allows easily printing a double with some whitespace to pad it out if it is smaller than expected. Its design roughly follows RawPointer which similarly allows special formatting of a kind of number. * WTF.xcodeproj/project.pbxproj: * wtf/CMakeLists.txt: * wtf/FixedWidthDouble.h: Added. (WTF::FixedWidthDouble::FixedWidthDouble): (WTF::FixedWidthDouble::value const): (WTF::FixedWidthDouble::width const): (WTF::FixedWidthDouble::precision const): * wtf/PrintStream.cpp: (WTF::printInternal): * wtf/PrintStream.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/b3/B3Compile.cpp trunk/Source/_javascript_Core/b3/B3FixSSA.cpp trunk/Source/_javascript_Core/b3/B3Generate.cpp trunk/Source/_javascript_Core/b3/B3PhaseScope.cpp trunk/Source/_javascript_Core/b3/B3PhaseScope.h trunk/Source/_javascript_Core/b3/B3VariableLiveness.cpp trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersAndStackByLinearScan.cpp trunk/Source/_javascript_Core/b3/air/AirGenerate.cpp trunk/Source/_javascript_Core/b3/air/AirLiveness.h trunk/Source/_javascript_Core/b3/air/AirPhaseScope.cpp trunk/Source/_javascript_Core/b3/air/AirPhaseScope.h trunk/Source/_javascript_Core/tools/CompilerTimingScope.cpp trunk/Source/WTF/ChangeLog trunk/Source/WTF/WTF.xcodeproj/project.pbxproj trunk/Source/WTF/wtf/CMakeLists.txt trunk/Source/WTF/wtf/PrintStream.cpp trunk/Source/WTF/wtf/PrintStream.h Added Paths trunk/Source/WTF/wtf/FixedWidthDouble.h Removed Paths trunk/Source/_javascript_Core/b3/B3TimingScope.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (290289 => 290290) --- trunk/Source/_javascript_Core/ChangeLog 2022-02-22 06:43:37 UTC (rev 290289) +++ trunk/Source/_javascript_Core/ChangeLog 2022-02-22 06:53:58 UTC (rev 290290) @@ -1,3 +1,57 @@ +2022-02-21 Robin Morisset + +[JSC] Format the output of --reportTotalPhaseTimes=1 more nicely +https://bugs.webkit.org/show_bug.cgi?id=237005 + +Reviewed by Saam Barati. + +Before this patch: +[B3] moveConstants total ms: 64.307583 max ms: 1.703167 +[B3] lowerToAir total ms: 151.297782 max ms: 5.426375 +[B3] generateToAir total ms: 1623.987166 max ms: 92.826750 +[B3] simplifyCFG total ms: 11.760463 max ms: 1.088083 +[B3] Air::lowerMacros total ms: 5.975679 max ms: 0.382000 + +After this patch: +total ms: 66.328 max ms: 2.283 [B3] moveConstants +total ms: 148.097 max ms: 5.361 [B3] lowerToAir +total ms: 1619.115 max ms: 96.307 [Total B3] generateToAir +
[webkit-changes] [289799] trunk/Source
Title: [289799] trunk/Source Revision 289799 Author rmoris...@apple.com Date 2022-02-15 01:37:07 -0800 (Tue, 15 Feb 2022) Log Message [WGSL] Implement enough of the lexer for the simplest shaders https://bugs.webkit.org/show_bug.cgi?id=233276 Reviewed by Myles Maxfield. Source/WebGPU: There is just enough of the lexer in this patch to pass the unit tests (also added by the patch). The lexer is templated by the character size, following the code from JSC's lexer. I did not use a lexer generator like lex for a few reasons: - It would have made the build system(s) even more of a nightmare - It would have made it harder to give accurate and customized error messages - If we ever decide to do anything exotic to the grammar of the language, it could have made it much harder The lexing of floating point literals is a bit hacky, and probably has some precision issues in corner cases, but it passed all simple unit tests, so for now I just left it as is with a FIXME, to be fixed once we can run the full CTS. The TokenType includes an `Invalid` value. I could instead have used std::optional everywhere. I made this choice for two reasons: - space efficiency: we don't use an extra word of memory for the variant's tag - (although this part could be solved by using https://github.com/akrzemi1/markable) - ease of use and time efficiency: everywhere that we check for a given TokenType, we would have to first check that the Token is not nullopt, and then check the TokenType. * Configurations/WGSLUnitTests.xcconfig: * WGSL/Lexer.cpp: Added. (WGSL::Lexer::lex): (WGSL::Lexer::shift): (WGSL::Lexer::peek): (WGSL::Lexer::skipWhitespace): (WGSL::Lexer::isAtEndOfFile const): (WGSL::Lexer::parseDecimalInteger): (WGSL::Lexer::parseDecimalFloatExponent): (WGSL::Lexer::parseIntegerLiteralSuffix): (WGSL::Lexer::isWhiteSpace): (WGSL::Lexer::isIdentifierStart): (WGSL::Lexer::isValidIdentifierCharacter): (WGSL::Lexer::isDecimal): (WGSL::Lexer::isHexadecimal): (WGSL::Lexer::readDecimal): (WGSL::Lexer::readHexadecimal): (WGSL::Lexer::isWhiteSpace): (WGSL::Lexer::isIdentifierStart): (WGSL::Lexer::isValidIdentifierCharacter): (WGSL::Lexer::isDecimal): (WGSL::Lexer::isHexadecimal): (WGSL::Lexer::readDecimal): (WGSL::Lexer::readHexadecimal): * WGSL/Lexer.h: Added. (WGSL::Lexer::Lexer): (WGSL::Lexer::currentPosition const): (WGSL::Lexer::currentOffset const): (WGSL::Lexer::currentTokenLength const): (WGSL::Lexer::makeToken): (WGSL::Lexer::makeLiteralToken): (WGSL::Lexer::makeIdentifierToken): * WGSL/SourceSpan.h: Added. (WGSL::SourceSpan::SourceSpan): * WGSL/Token.cpp: Added. (WGSL::toString): * WGSL/Token.h: Added. (WGSL::Token::Token): (WGSL::Token::operator=): (WGSL::Token::~Token): * WGSL/WGSL.cpp: (WGSL::staticCheck): * WGSLUnitTests/WGSLLexerTests.mm: Added. (-[WGSLLexerTests testLexerOnSingleTokens]): (-[WGSLLexerTests testLexerOnComputeShader]): (-[WGSLLexerTests testLexerOnGraphicsShader]): * WGSLUnitTests/WGSLUnitTests.mm: Removed. (-[WGSLUnitTests testExample]): Deleted. * WebGPU.xcodeproj/project.pbxproj: Source/WTF: Add WTF::Unicode::formFeed and WTF::Unicode::verticalTabulation. * wtf/unicode/CharacterNames.h: Modified Paths trunk/Source/WTF/ChangeLog trunk/Source/WTF/wtf/unicode/CharacterNames.h trunk/Source/WebGPU/ChangeLog trunk/Source/WebGPU/WGSL/WGSL.cpp trunk/Source/WebGPU/WebGPU.xcodeproj/project.pbxproj Added Paths trunk/Source/WebGPU/WGSL/Lexer.cpp trunk/Source/WebGPU/WGSL/Lexer.h trunk/Source/WebGPU/WGSL/SourceSpan.h trunk/Source/WebGPU/WGSL/Token.cpp trunk/Source/WebGPU/WGSL/Token.h trunk/Source/WebGPU/WGSLUnitTests/WGSLLexerTests.mm Removed Paths trunk/Source/WebGPU/WGSLUnitTests/WGSLUnitTests.mm Diff Modified: trunk/Source/WTF/ChangeLog (289798 => 289799) --- trunk/Source/WTF/ChangeLog 2022-02-15 09:23:39 UTC (rev 289798) +++ trunk/Source/WTF/ChangeLog 2022-02-15 09:37:07 UTC (rev 289799) @@ -1,3 +1,15 @@ +2022-02-15 Robin Morisset + +[WGSL] Implement enough of the lexer for the simplest shaders +https://bugs.webkit.org/show_bug.cgi?id=233276 + + +Reviewed by Myles Maxfield. + +Add WTF::Unicode::formFeed and WTF::Unicode::verticalTabulation. + +* wtf/unicode/CharacterNames.h: + 2022-02-14 Gustavo Noronha Silva [Linux/aarch64] Move page size ceiling to 16k Modified: trunk/Source/WTF/wtf/unicode/CharacterNames.h (289798 => 289799) --- trunk/Source/WTF/wtf/unicode/CharacterNames.h 2022-02-15 09:23:39 UTC (rev 289798) +++ trunk/Source/WTF/wtf/unicode/CharacterNames.h 2022-02-15 09:37:07 UTC (rev 289799) @@ -62,6 +62,7 @@ constexpr UChar horizontalEllipsis = 0x2026; constexpr UChar hyphen = 0x2010; constexpr UChar enDash = 0x2013; +constexpr UChar formFeed = 0x000C; constexpr UChar hyphenMinus = 0x002D; constexpr UChar ideographicComma = 0x3001; constexpr UChar ideographicFullStop = 0x3002; @@ -103,6 +104,7 @@ constexpr UChar tibetanMarkIntersyllabicTsheg = 0x0F0B; constexpr UChar32 ugariticWordDivider = 0x1039F;
[webkit-changes] [286053] trunk/Source/JavaScriptCore
Title: [286053] trunk/Source/_javascript_Core
Revision 286053
Author rmoris...@apple.com
Date 2021-11-19 01:38:27 -0800 (Fri, 19 Nov 2021)
Log Message
AirFixObviousSpills should be optimized
https://bugs.webkit.org/show_bug.cgi?id=228052
Reviewed by Yusuke Suzuki.
There were two problems with AirFixObviousSpills:
- merge() had a quadratic blow-up, as for each element in a vector, it was searching it in a different vector.
- it would visit blocks even when their state at head had not changed.
I fixed the first problem by making sure that the vectors are sorted before calling merge, and making use of that invariant in the search of the vectors
(see filterVectorAgainst)
This reduced the total time spent in that phase from 390ms to 230ms, and the worst case time spent in that phase for one function from 100ms to 30ms (all of the results in this Changelog are for JetStream2 on a M1 MBP).
I fixed the second problem even more easily by adding a m_shouldVisit BitVector. I also moved the m_wasVisited boolean that was in State to a m_notBottom BitVector for simplicity and symmetry.
That change further reduced the total/max time from 230ms/30ms to 140ms/16ms.
* b3/air/AirFixObviousSpills.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/air/AirFixObviousSpills.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (286052 => 286053)
--- trunk/Source/_javascript_Core/ChangeLog 2021-11-19 09:01:37 UTC (rev 286052)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-11-19 09:38:27 UTC (rev 286053)
@@ -1,3 +1,23 @@
+2021-11-19 Robin Morisset
+
+AirFixObviousSpills should be optimized
+https://bugs.webkit.org/show_bug.cgi?id=228052
+
+Reviewed by Yusuke Suzuki.
+
+There were two problems with AirFixObviousSpills:
+- merge() had a quadratic blow-up, as for each element in a vector, it was searching it in a different vector.
+- it would visit blocks even when their state at head had not changed.
+
+I fixed the first problem by making sure that the vectors are sorted before calling merge, and making use of that invariant in the search of the vectors
+(see filterVectorAgainst)
+This reduced the total time spent in that phase from 390ms to 230ms, and the worst case time spent in that phase for one function from 100ms to 30ms (all of the results in this Changelog are for JetStream2 on a M1 MBP).
+
+I fixed the second problem even more easily by adding a m_shouldVisit BitVector. I also moved the m_wasVisited boolean that was in State to a m_notBottom BitVector for simplicity and symmetry.
+That change further reduced the total/max time from 230ms/30ms to 140ms/16ms.
+
+* b3/air/AirFixObviousSpills.cpp:
+
2021-11-18 Robin Morisset
[JSC/Air] Optimize enableMovesOnValueAndAdjacents in IRC
Modified: trunk/Source/_javascript_Core/b3/air/AirFixObviousSpills.cpp (286052 => 286053)
--- trunk/Source/_javascript_Core/b3/air/AirFixObviousSpills.cpp 2021-11-19 09:01:37 UTC (rev 286052)
+++ trunk/Source/_javascript_Core/b3/air/AirFixObviousSpills.cpp 2021-11-19 09:38:27 UTC (rev 286053)
@@ -48,6 +48,8 @@
FixObviousSpills(Code& code)
: m_code(code)
, m_atHead(code.size())
+, m_notBottom(code.size())
+, m_shouldVisit(code.size())
{
}
@@ -63,17 +65,19 @@
private:
void computeAliases()
{
-m_atHead[m_code[0]].wasVisited = true;
+m_notBottom.quickSet(0);
+m_shouldVisit.quickSet(0);
bool changed = true;
while (changed) {
changed = false;
-for (BasicBlock* block : m_code) {
+for (unsigned blockIndex : m_shouldVisit) {
+m_shouldVisit.quickClear(blockIndex);
+BasicBlock* block = m_code[blockIndex];
+ASSERT(m_notBottom.quickGet(blockIndex));
m_block = block;
m_state = m_atHead[block];
-if (!m_state.wasVisited)
-continue;
if (AirFixObviousSpillsInternal::verbose)
dataLog("Executing block ", *m_block, ": ", m_state, "\n");
@@ -81,13 +85,23 @@
for (m_instIndex = 0; m_instIndex < block->size(); ++m_instIndex)
executeInst();
+// Before we call merge we must make sure that the two states are sorted.
+m_state.sort();
+
for (BasicBlock* successor : block->successorBlocks()) {
+unsigned successorIndex = successor->index();
State& toState = m_atHead[successor];
-if (toState.wasVisited)
-changed |= toState.merge(m_state);
-else {
+if (m_notBottom.quickGet(successorIndex)) {
+bool changedAtSuccessorHead = toState.merge(m_state);
+
[webkit-changes] [286045] trunk/Source/JavaScriptCore
Title: [286045] trunk/Source/_javascript_Core
Revision 286045
Author rmoris...@apple.com
Date 2021-11-18 22:06:32 -0800 (Thu, 18 Nov 2021)
Log Message
[JSC/Air] Optimize enableMovesOnValueAndAdjacents in IRC
https://bugs.webkit.org/show_bug.cgi?id=228615
Reviewed by Saam Barati.
The Iterated Register Coalescing (IRC) register allocator spends a very significant fraction of its time in JS2 in enableMovesOnValueAndAdjacents (816ms out of 2.07s spent in register allocation for Wasm code in one run I looked at with Instruments).
The reason is that if this function is called on N nodes that are neighbors of each other, then enableMovesOnValue (which is kinda expensive as it iterates a SmallSet which is not always small) will be called N times on each of the N nodes. This can trivially be fixed by keeping track of which nodes need enableMovesOnValue called on them and only calling it on them once.
It is a bit tricky to measure the performance impact of this, as it heavily depends on whether some very large functions reach Air or not, so there is a lot of noise.
Here are the numbers out of 4 runs of JS2 (cli version) on an M1 MBP with --airForceIRCAllocator=1:
Baseline : total time in allocateRegistersByGraphColoring ranges from 2090ms to 3018ms, most time for a single function ranges from 631ms to 849ms
With this patch: total time in allocateRegistersByGraphColoring ranges from 1580ms to 2333ms, most time for a single function ranges from 337ms to 560ms
So despite the noise it seems quite clearly a win.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (286044 => 286045)
--- trunk/Source/_javascript_Core/ChangeLog 2021-11-19 04:18:12 UTC (rev 286044)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-11-19 06:06:32 UTC (rev 286045)
@@ -1,3 +1,21 @@
+2021-11-18 Robin Morisset
+
+[JSC/Air] Optimize enableMovesOnValueAndAdjacents in IRC
+https://bugs.webkit.org/show_bug.cgi?id=228615
+
+Reviewed by Saam Barati.
+
+The Iterated Register Coalescing (IRC) register allocator spends a very significant fraction of its time in JS2 in enableMovesOnValueAndAdjacents (816ms out of 2.07s spent in register allocation for Wasm code in one run I looked at with Instruments).
+The reason is that if this function is called on N nodes that are neighbors of each other, then enableMovesOnValue (which is kinda expensive as it iterates a SmallSet which is not always small) will be called N times on each of the N nodes. This can trivially be fixed by keeping track of which nodes need enableMovesOnValue called on them and only calling it on them once.
+
+It is a bit tricky to measure the performance impact of this, as it heavily depends on whether some very large functions reach Air or not, so there is a lot of noise.
+Here are the numbers out of 4 runs of JS2 (cli version) on an M1 MBP with --airForceIRCAllocator=1:
+Baseline : total time in allocateRegistersByGraphColoring ranges from 2090ms to 3018ms, most time for a single function ranges from 631ms to 849ms
+With this patch: total time in allocateRegistersByGraphColoring ranges from 1580ms to 2333ms, most time for a single function ranges from 337ms to 560ms
+So despite the noise it seems quite clearly a win.
+
+* b3/air/AirAllocateRegistersByGraphColoring.cpp:
+
2021-11-18 Mark Lam
SubSpace constructors should take a const HeapCellType& instead of a HeapCellType*.
Modified: trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp (286044 => 286045)
--- trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2021-11-19 04:18:12 UTC (rev 286044)
+++ trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2021-11-19 06:06:32 UTC (rev 286045)
@@ -912,6 +912,7 @@
public:
IRC(Code& code, const Vector& regsInPriorityOrder, IndexType lastPrecoloredRegisterIndex, unsigned tmpArraySize, const BitVector& unspillableTmps, const UseCounts& useCounts)
: Base(code, regsInPriorityOrder, lastPrecoloredRegisterIndex, tmpArraySize, unspillableTmps, useCounts)
+, m_movesToEnable(tmpArraySize)
{
}
@@ -941,6 +942,8 @@
if (!m_simplifyWorklist.isEmpty())
simplify();
+else if (!m_movesToEnable.isEmpty())
+enableMoves();
else if (!m_worklistMoves.isEmpty())
coalesce();
else if (!m_freezeWorklist.isEmpty())
@@ -1103,7 +1106,7 @@
unsigned oldDegree = m_degrees[tmpIndex]--;
if (oldDegree == registerCount()) {
-enableMovesOnValueAndAdjacents(tmpIndex);
+lazyEnableMovesOnValueAndAdjacents(tmpIndex);
m_spillWorklist.quickClear(tmpIndex);
[webkit-changes] [286030] trunk/Source/JavaScriptCore
Title: [286030] trunk/Source/_javascript_Core Revision 286030 Author rmoris...@apple.com Date 2021-11-18 14:56:56 -0800 (Thu, 18 Nov 2021) Log Message DFGByteCodeParser.cpp should avoid resizing the Operands<> of every BasicBlock on every inlining https://bugs.webkit.org/show_bug.cgi?id=228053 Reviewed by Saam Barati. The dfg bytecode parser only makes use of block->variablesAtTail. But currently it updates the size of variablesAtHead, valuesAtHead, valuesAtTail and intersectionOfPastValuesAtHead every single time it changes the number of Tmps and/or Locals. This happens notably whenever it inlines a function. It is not nearly as cheap as it looks, as each resizing may reallocate a Vector, requires filling the new slots with zeros, and requires moving the existing values (which are all 0) to the new Vector. This was obvious when looking at profiling of JS2: bzero + memmove are the two hottest C++ functions, and the manipulation of Operands is partly responsible. This patch fixes this by only resizing block->variablesAtTail during the execution of the bytecode parser, and initializing all of the other operands at the very end of it. It also merges the adjustment of numLocals and of numTmps for variablesAtTail during inlining, to avoid accidentally moving data twice. On JetStream2 on an M1 MBP, it changes the total time spent in the DFGByteCodeParser from 1240-1260ms to 1155-1170ms. * bytecode/Operands.h: (JSC::Operands::ensureLocalsAndTmps): * dfg/DFGBasicBlock.cpp: * dfg/DFGBasicBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ensureLocalsForVariablesAtTail): (JSC::DFG::ByteCodeParser::ensureLocalsAndTmpsForVariablesAtTail): (JSC::DFG::ByteCodeParser::allocateBlock): (JSC::DFG::ByteCodeParser::allocateTargetableBlock): (JSC::DFG::ByteCodeParser::allocateUntargetableBlock): (JSC::DFG::ByteCodeParser::inlineCall): (JSC::DFG::ByteCodeParser::handleVarargsInlining): (JSC::DFG::ByteCodeParser::handleGetById): (JSC::DFG::ByteCodeParser::handlePutById): (JSC::DFG::ByteCodeParser::parse): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/bytecode/Operands.h trunk/Source/_javascript_Core/dfg/DFGBasicBlock.cpp trunk/Source/_javascript_Core/dfg/DFGBasicBlock.h trunk/Source/_javascript_Core/dfg/DFGByteCodeParser.cpp Diff Modified: trunk/Source/_javascript_Core/ChangeLog (286029 => 286030) --- trunk/Source/_javascript_Core/ChangeLog 2021-11-18 22:21:54 UTC (rev 286029) +++ trunk/Source/_javascript_Core/ChangeLog 2021-11-18 22:56:56 UTC (rev 286030) @@ -1,3 +1,38 @@ +2021-11-18 Robin Morisset + +DFGByteCodeParser.cpp should avoid resizing the Operands<> of every BasicBlock on every inlining +https://bugs.webkit.org/show_bug.cgi?id=228053 + +Reviewed by Saam Barati. + +The dfg bytecode parser only makes use of block->variablesAtTail. +But currently it updates the size of variablesAtHead, valuesAtHead, valuesAtTail and intersectionOfPastValuesAtHead every single time it changes the number of Tmps and/or Locals. +This happens notably whenever it inlines a function. + +It is not nearly as cheap as it looks, as each resizing may reallocate a Vector, requires filling the new slots with zeros, and requires moving the existing values (which are all 0) to the new Vector. +This was obvious when looking at profiling of JS2: bzero + memmove are the two hottest C++ functions, and the manipulation of Operands is partly responsible. + +This patch fixes this by only resizing block->variablesAtTail during the execution of the bytecode parser, and initializing all of the other operands at the very end of it. +It also merges the adjustment of numLocals and of numTmps for variablesAtTail during inlining, to avoid accidentally moving data twice. + +On JetStream2 on an M1 MBP, it changes the total time spent in the DFGByteCodeParser from 1240-1260ms to 1155-1170ms. + +* bytecode/Operands.h: +(JSC::Operands::ensureLocalsAndTmps): +* dfg/DFGBasicBlock.cpp: +* dfg/DFGBasicBlock.h: +* dfg/DFGByteCodeParser.cpp: +(JSC::DFG::ByteCodeParser::ensureLocalsForVariablesAtTail): +(JSC::DFG::ByteCodeParser::ensureLocalsAndTmpsForVariablesAtTail): +(JSC::DFG::ByteCodeParser::allocateBlock): +(JSC::DFG::ByteCodeParser::allocateTargetableBlock): +(JSC::DFG::ByteCodeParser::allocateUntargetableBlock): +(JSC::DFG::ByteCodeParser::inlineCall): +(JSC::DFG::ByteCodeParser::handleVarargsInlining): +(JSC::DFG::ByteCodeParser::handleGetById): +(JSC::DFG::ByteCodeParser::handlePutById): +(JSC::DFG::ByteCodeParser::parse): + 2021-11-18 Yusuke Suzuki [JSC] Add branchTest16 operation Modified: trunk/Source/_javascript_Core/bytecode/Operands.h (286029 => 286030) --- trunk/Source/_javascript_Core/bytecode/Operands.h 2021-11-18 22:21:54 UTC (rev 286029) +++
[webkit-changes] [285533] trunk/Source/JavaScriptCore
Title: [285533] trunk/Source/_javascript_Core Revision 285533 Author rmoris...@apple.com Date 2021-11-09 13:56:05 -0800 (Tue, 09 Nov 2021) Log Message Using WASM function size as the cap for choosing a register allocator causes performance regressions. https://bugs.webkit.org/show_bug.cgi?id=217290 Reviewed by Yusuke Suzuki. This patch just increases --maximumTmpsForGraphColoring from 25k to 60k. It was originally lowered to prevent jetsams in some wasm webpages such as mruby-wasm.aotoki.dev. These jetsams were caused by excessive memory consumption by the interference graphs used by AirAllocateRegistersByGraphColoring and AirAllocateStackByGraphColoring. I massively optimized these interference graphs in the following two patches (effect on mruby-wasm.aotoki.dev): - https://trac.webkit.org/changeset/277714/webkit (262MB + 262MB -> 20MB + 10MB in register allocator) - https://trac.webkit.org/changeset/278186/webkit (221MB + 399MB -> 6.5MB + 10.5MB in stack slot allocator) So it should now be safe to increase --maximumTmpsForGraphColoring. It is valuable to increase it, because some webpages such as https://dos.zone/en/play/https%3A%2F%2Fdoszone-uploads.s3.dualstack.eu-central-1.amazonaws.com%2Foriginal%2F2X%2Fb%2Fb4b5275904d86a4ab8a20917b2b7e34f0df47bf7.jsdos see massive performance wins/losses depending on whether we register allocate all of their wasm functions or not. For example that page has two functions with ~54k temporaries, and its integrated benchmark has a score increase from about 27 to about 70 on an M1 MBP 2020 when they are register allocated. External reports suggest that this the performance difference is even larger on older machines (5.5 to 48). * runtime/OptionsList.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/runtime/OptionsList.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (285532 => 285533) --- trunk/Source/_javascript_Core/ChangeLog 2021-11-09 21:53:02 UTC (rev 285532) +++ trunk/Source/_javascript_Core/ChangeLog 2021-11-09 21:56:05 UTC (rev 285533) @@ -1,3 +1,26 @@ +2021-11-09 Robin Morisset + +Using WASM function size as the cap for choosing a register allocator causes performance regressions. +https://bugs.webkit.org/show_bug.cgi?id=217290 + + +Reviewed by Yusuke Suzuki. + +This patch just increases --maximumTmpsForGraphColoring from 25k to 60k. + +It was originally lowered to prevent jetsams in some wasm webpages such as mruby-wasm.aotoki.dev. +These jetsams were caused by excessive memory consumption by the interference graphs used by AirAllocateRegistersByGraphColoring and AirAllocateStackByGraphColoring. +I massively optimized these interference graphs in the following two patches (effect on mruby-wasm.aotoki.dev): +- https://trac.webkit.org/changeset/277714/webkit (262MB + 262MB -> 20MB + 10MB in register allocator) +- https://trac.webkit.org/changeset/278186/webkit (221MB + 399MB -> 6.5MB + 10.5MB in stack slot allocator) +So it should now be safe to increase --maximumTmpsForGraphColoring. + +It is valuable to increase it, because some webpages such as https://dos.zone/en/play/https%3A%2F%2Fdoszone-uploads.s3.dualstack.eu-central-1.amazonaws.com%2Foriginal%2F2X%2Fb%2Fb4b5275904d86a4ab8a20917b2b7e34f0df47bf7.jsdos see massive performance wins/losses depending on whether we register allocate all of their wasm functions or not. +For example that page has two functions with ~54k temporaries, and its integrated benchmark has a score increase from about 27 to about 70 on an M1 MBP 2020 when they are register allocated. +External reports suggest that this the performance difference is even larger on older machines (5.5 to 48). + +* runtime/OptionsList.h: + 2021-11-09 Zan Dobersek [RISCV64] Add assembly, disassembly infrastructure Modified: trunk/Source/_javascript_Core/runtime/OptionsList.h (285532 => 285533) --- trunk/Source/_javascript_Core/runtime/OptionsList.h 2021-11-09 21:53:02 UTC (rev 285532) +++ trunk/Source/_javascript_Core/runtime/OptionsList.h 2021-11-09 21:56:05 UTC (rev 285533) @@ -423,7 +423,7 @@ \ v(Bool, logPhaseTimes, false, Normal, nullptr) \ v(Double, rareBlockPenalty, 0.001, Normal, nullptr) \ -v(Unsigned, maximumTmpsForGraphColoring, 25000, Normal, "The maximum number of tmps an Air program can have before always register allocating with Linear Scan") \ +v(Unsigned, maximumTmpsForGraphColoring, 6, Normal, "The maximum number of tmps an Air program can have before always register allocating with Linear Scan") \ v(Bool, airLinearScanVerbose, false, Normal, nullptr) \ v(Bool, airLinearScanSpillsEverything, false, Normal, nullptr) \ v(Bool, airForceBriggsAllocator, false, Normal, nullptr) \ ___ webkit-changes mailing list webkit-changes@lists.webkit.org
[webkit-changes] [285191] trunk
Title: [285191] trunk
Revision 285191
Author rmoris...@apple.com
Date 2021-11-02 18:27:28 -0700 (Tue, 02 Nov 2021)
Log Message
Regression (r284330): [ macOS wk1 Debug ] webaudio/AudioBuffer/huge-buffer.html is a flaky timeout
https://bugs.webkit.org/show_bug.cgi?id=232244
Reviewed by Yusuke Suzuki.
Source/WebCore:
The test is verifying that trying to allocate an AudioBuffer with 4GB channels fails cleanly.
It used to work automatically, as AudioBuffer relies on Float32Array under the hood, which was limited to 2GB.
Since r284330, ArrayBuffers can be up to 4GB, so it now takes very long to OOM, and sometimes timeout.
I use the same solution which I used for PixelBuffers in r284330: just test that the length is reasonable
and if it is not then abort as if the allocation of the Float32Array had failed.
No new tests: covered by LayoutTests/webaudio/AudioBuffer/huge-buffer.html
* Modules/webaudio/AudioBuffer.cpp:
(WebCore::AudioBuffer::AudioBuffer):
* Modules/webaudio/AudioBuffer.h:
LayoutTests:
* platform/mac-wk1/TestExpectations:
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/platform/mac-wk1/TestExpectations
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp
trunk/Source/WebCore/Modules/webaudio/AudioBuffer.h
Diff
Modified: trunk/LayoutTests/ChangeLog (285190 => 285191)
--- trunk/LayoutTests/ChangeLog 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/LayoutTests/ChangeLog 2021-11-03 01:27:28 UTC (rev 285191)
@@ -1,3 +1,13 @@
+2021-11-02 Robin Morisset
+
+Regression (r284330): [ macOS wk1 Debug ] webaudio/AudioBuffer/huge-buffer.html is a flaky timeout
+https://bugs.webkit.org/show_bug.cgi?id=232244
+
+
+Reviewed by Yusuke Suzuki.
+
+* platform/mac-wk1/TestExpectations:
+
2021-11-02 Tyler Wilcock
AX: WebKit needs to include NSAccessibilityChildrenInNavigationOrderAttribute in accessibilityAttributeNames
Modified: trunk/LayoutTests/platform/mac-wk1/TestExpectations (285190 => 285191)
--- trunk/LayoutTests/platform/mac-wk1/TestExpectations 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/LayoutTests/platform/mac-wk1/TestExpectations 2021-11-03 01:27:28 UTC (rev 285191)
@@ -1385,8 +1385,6 @@
webkit.org/b/228796 [ BigSur+ ] webaudio/silent-audio-interrupted-in-background.html [ Pass Timeout ]
webkit.org/b/228796 [ Catalina Debug ] webaudio/silent-audio-interrupted-in-background.html [ Pass Timeout ]
-webkit.org/b/232244 [ Debug ] webaudio/AudioBuffer/huge-buffer.html [ Pass Timeout ]
-
webkit.org/b/227136 media/video-pause-immediately.html [ Pass Failure ]
webkit.org/b/228084 [ BigSur Release ] media/video-restricted-no-preload-auto.html [ Pass Failure ]
Modified: trunk/Source/WebCore/ChangeLog (285190 => 285191)
--- trunk/Source/WebCore/ChangeLog 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/Source/WebCore/ChangeLog 2021-11-03 01:27:28 UTC (rev 285191)
@@ -1,3 +1,23 @@
+2021-11-02 Robin Morisset
+
+Regression (r284330): [ macOS wk1 Debug ] webaudio/AudioBuffer/huge-buffer.html is a flaky timeout
+https://bugs.webkit.org/show_bug.cgi?id=232244
+
+
+Reviewed by Yusuke Suzuki.
+
+The test is verifying that trying to allocate an AudioBuffer with 4GB channels fails cleanly.
+It used to work automatically, as AudioBuffer relies on Float32Array under the hood, which was limited to 2GB.
+Since r284330, ArrayBuffers can be up to 4GB, so it now takes very long to OOM, and sometimes timeout.
+I use the same solution which I used for PixelBuffers in r284330: just test that the length is reasonable
+and if it is not then abort as if the allocation of the Float32Array had failed.
+
+No new tests: covered by LayoutTests/webaudio/AudioBuffer/huge-buffer.html
+
+* Modules/webaudio/AudioBuffer.cpp:
+(WebCore::AudioBuffer::AudioBuffer):
+* Modules/webaudio/AudioBuffer.h:
+
2021-11-02 Don Olmstead
SVG elements should include SVGElementInlines not ElementInlines
Modified: trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp (285190 => 285191)
--- trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp 2021-11-03 01:00:54 UTC (rev 285190)
+++ trunk/Source/WebCore/Modules/webaudio/AudioBuffer.cpp 2021-11-03 01:27:28 UTC (rev 285191)
@@ -86,6 +86,11 @@
, m_originalLength(length)
, m_isDetachable(preventDetaching == LegacyPreventDetaching::No)
{
+if (static_cast(m_originalLength) > s_maxLength) {
+invalidate();
+return;
+}
+
m_channels.reserveCapacity(numberOfChannels);
for (unsigned i = 0; i < numberOfChannels; ++i) {
@@ -107,6 +112,11 @@
: m_sampleRate(bus.sampleRate())
, m_originalLength(bus.length())
{
+if (static_cast(m_originalLength) > s_maxLength) {
+invalidate();
+return;
+}
+
// Copy audio data from the bus to the Float32Arrays we manage.
unsigned numberOfChannels =
[webkit-changes] [285117] trunk
Title: [285117] trunk Revision 285117 Author rmoris...@apple.com Date 2021-11-01 11:01:21 -0700 (Mon, 01 Nov 2021) Log Message JSGenericTypedArrayView::set crashes if the length + objectOffset is > UINT32_MAX https://bugs.webkit.org/show_bug.cgi?id=231975 rdar://84402043 Reviewed by Yusuke Suzuki. JSTests: - regress-84402043 is the testcase that revealed the problem. - typed-array-set-large(-offset) test the same function, in the typed-array to typed-array case - typed-array-large-slice tests the only caller that passes a non-0 objectOffset, and found other issues with it - typed-array-large-oob-eventually-not.js is just another test of the Wasm4GB change that I had forgotten to commit * stress/regress-84402043.js: Added. * stress/typed-array-large-oob-eventually-not.js: Added. (test): * stress/typed-array-large-slice.js: Added. (expect): * stress/typed-array-set-large-offset.js: Added. * stress/typed-array-set-large.js: Added. Source/_javascript_Core: UINT_MAX (and anything above it) is not a valid array index, so we cannot use JSObject::get(JSGlobalObject*, unsigned) with an index that big. This was pointed by Yusuke in his review of my recent patch that introduced the problem (https://bugs.webkit.org/show_bug.cgi?id=229353#c21), but I misunderstood the code and thought we could never get values that big at that point, thus only putting a RELEASE_ASSERT. In this patch I instead apply his original suggestion to have a first loop using the (fast) JSObject::get(), and a second loop for any large indices, using a slower but safe code path. I also fixed an unrelated bug I noticed in Clobberize/AbstractInterpreter while testing the rest of the patch: they were not aware that NewTypedArray can take a Int52RepUse child. Finally, while trying to properly test this change, I discovered that genericTypedArrayViewProtoFuncSlice (which is the only caller of JSGenericTypedArrayView::set which passes it a non-0 objectOffset) was still using unsigned everywhere instead of size_t, and that the same was true of all other functions in the same file. So I fixed it in the same patch. * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * runtime/JSArrayBufferConstructor.cpp: (JSC::JSGenericArrayBufferConstructor::constructImpl): * runtime/JSGenericTypedArrayViewConstructorInlines.h: (JSC::constructGenericTypedArrayViewImpl): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView::set): * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: (JSC::argumentClampedIndexFromStartOrEnd): (JSC::genericTypedArrayViewProtoFuncSet): (JSC::genericTypedArrayViewProtoFuncCopyWithin): (JSC::genericTypedArrayViewProtoFuncIncludes): (JSC::genericTypedArrayViewProtoFuncIndexOf): (JSC::genericTypedArrayViewProtoFuncJoin): (JSC::genericTypedArrayViewProtoFuncFill): (JSC::genericTypedArrayViewProtoFuncLastIndexOf): (JSC::genericTypedArrayViewProtoFuncSlice): (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): Modified Paths trunk/JSTests/ChangeLog trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/dfg/DFGAbstractInterpreterInlines.h trunk/Source/_javascript_Core/dfg/DFGClobberize.h trunk/Source/_javascript_Core/runtime/JSArrayBufferConstructor.cpp trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewConstructorInlines.h trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewInlines.h trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewPrototypeFunctions.h Added Paths trunk/JSTests/stress/regress-84402043.js trunk/JSTests/stress/typed-array-large-oob-eventually-not.js trunk/JSTests/stress/typed-array-large-slice.js trunk/JSTests/stress/typed-array-set-large-offset.js trunk/JSTests/stress/typed-array-set-large.js Diff Modified: trunk/JSTests/ChangeLog (285116 => 285117) --- trunk/JSTests/ChangeLog 2021-11-01 17:50:16 UTC (rev 285116) +++ trunk/JSTests/ChangeLog 2021-11-01 18:01:21 UTC (rev 285117) @@ -1,3 +1,24 @@ +2021-11-01 Robin Morisset + +JSGenericTypedArrayView::set crashes if the length + objectOffset is > UINT32_MAX +https://bugs.webkit.org/show_bug.cgi?id=231975 +rdar://84402043 + +Reviewed by Yusuke Suzuki. + +- regress-84402043 is the testcase that revealed the problem. +- typed-array-set-large(-offset) test the same function, in the typed-array to typed-array case +- typed-array-large-slice tests the only caller that passes a non-0 objectOffset, and found other issues with it +- typed-array-large-oob-eventually-not.js is just another test of the Wasm4GB change that I had forgotten to commit + +* stress/regress-84402043.js: Added. +* stress/typed-array-large-oob-eventually-not.js: Added. +(test): +* stress/typed-array-large-slice.js: Added. +(expect): +* stress/typed-array-set-large-offset.js: Added. +* stress/typed-array-set-large.js:
[webkit-changes] [284690] trunk/Source/JavaScriptCore
Title: [284690] trunk/Source/_javascript_Core
Revision 284690
Author rmoris...@apple.com
Date 2021-10-22 09:36:49 -0700 (Fri, 22 Oct 2021)
Log Message
--reportBytecodeCompileTimes=1 should correctly report the bytecode size
https://bugs.webkit.org/show_bug.cgi?id=232118
Reviewed by Michael Saboff.
generate() calls m_writer.finalize() which moves m_instructions, so when we later query its size we get 0.
The solution is simply to put the size in an out-parameter just before calling finalize().
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generate):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp
trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (284689 => 284690)
--- trunk/Source/_javascript_Core/ChangeLog 2021-10-22 16:31:34 UTC (rev 284689)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-10-22 16:36:49 UTC (rev 284690)
@@ -1,3 +1,18 @@
+2021-10-22 Robin Morisset
+
+--reportBytecodeCompileTimes=1 should correctly report the bytecode size
+https://bugs.webkit.org/show_bug.cgi?id=232118
+
+Reviewed by Michael Saboff.
+
+generate() calls m_writer.finalize() which moves m_instructions, so when we later query its size we get 0.
+The solution is simply to put the size in an out-parameter just before calling finalize().
+
+* bytecompiler/BytecodeGenerator.cpp:
+(JSC::BytecodeGenerator::generate):
+* bytecompiler/BytecodeGenerator.h:
+(JSC::BytecodeGenerator::generate):
+
2021-10-22 Mark Lam
Remove unneeded Heap::m_vm.
Modified: trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp (284689 => 284690)
--- trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp 2021-10-22 16:31:34 UTC (rev 284689)
+++ trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp 2021-10-22 16:36:49 UTC (rev 284690)
@@ -148,7 +148,7 @@
generator.moveEmptyValue(completionValueRegister());
}
-ParserError BytecodeGenerator::generate()
+ParserError BytecodeGenerator::generate(unsigned& size)
{
if (UNLIKELY(m_outOfMemoryDuringConstruction))
return ParserError(ParserError::OutOfMemory);
@@ -285,6 +285,7 @@
performGeneratorification(*this, m_codeBlock.get(), m_writer, m_generatorFrameSymbolTable.get(), m_generatorFrameSymbolTableIndex);
RELEASE_ASSERT(m_codeBlock->numCalleeLocals() < static_cast(FirstConstantRegisterIndex));
+size = instructions().size();
m_codeBlock->finalize(m_writer.finalize());
if (m_expressionTooDeep)
return ParserError(ParserError::OutOfMemory);
Modified: trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.h (284689 => 284690)
--- trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.h 2021-10-22 16:31:34 UTC (rev 284689)
+++ trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.h 2021-10-22 16:36:49 UTC (rev 284690)
@@ -384,11 +384,12 @@
DeferGC deferGC(vm.heap);
auto bytecodeGenerator = makeUnique(vm, node, unlinkedCodeBlock, codeGenerationMode, parentScopeTDZVariables, privateNameEnvironment);
-auto result = bytecodeGenerator->generate();
+unsigned size;
+auto result = bytecodeGenerator->generate(size);
if (UNLIKELY(Options::reportBytecodeCompileTimes())) {
MonotonicTime after = MonotonicTime::now();
-dataLogLn(result.isValid() ? "Failed to compile #" : "Compiled #", CodeBlockHash(sourceCode, unlinkedCodeBlock->isConstructor() ? CodeForConstruct : CodeForCall), " into bytecode ", bytecodeGenerator->instructions().size(), " instructions in ", (after - before).milliseconds(), " ms.");
+dataLogLn(result.isValid() ? "Failed to compile #" : "Compiled #", CodeBlockHash(sourceCode, unlinkedCodeBlock->isConstructor() ? CodeForConstruct : CodeForCall), " into bytecode ", size, " instructions in ", (after - before).milliseconds(), " ms.");
}
return result;
}
@@ -1074,7 +1075,7 @@
int labelScopeDepth() const;
private:
-ParserError generate();
+ParserError generate(unsigned&);
Variable variableForLocalEntry(const Identifier&, const SymbolTableEntry&, int symbolTableConstantIndex, bool isLexicallyScoped);
RegisterID* kill(RegisterID* dst)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [282200] trunk
Title: [282200] trunk Revision 282200 Author rmoris...@apple.com Date 2021-09-09 01:10:20 -0700 (Thu, 09 Sep 2021) Log Message Optimize compareStrictEq when neither side is a double and at least one is not a BigInt https://bugs.webkit.org/show_bug.cgi?id=226755 Reviewed by Yusuke Suzuki. JSTests: Made the error messages in stress/reflect-set a bit more informative in the process of debugging an issue with the patch. * stress/reflect-set.js: (shouldBe): (shouldThrow): Source/_javascript_Core: This is a very similar patch to https://bugs.webkit.org/show_bug.cgi?id=226676. The difference is that here we allow Strings on both side of the comparison, so we must add code to handle equality among strings. Like for that other patch, the optimization is disabled for BigInt32. Enabling it in that case would either need modifying the speculation (from banning HeapBigInt to banning all BigInts), or ensuring that we can never have a HeapBigInt so small it compares equal to a BigInt32. I only implemented this optimization on 64-bits: it is just painful to write code that handles registers at such a low-level without a 32-bit machine to test things locally. If anyone wants to make this optimization work on 32-bit, I don't foretell any major difficulty. Finally, like quite a few other useKinds already, this case does not make the CompareStrictEq merge with an adjacent Branch. The reason is simply that this patch relies on compileStringEquality, which currently does not support that feature. I intend to fix this (for all useKinds at once) in a separate patch. Effect on microbenchmarks: poly-stricteq-not-double 46.8000+-0.4110 ^ 23.5872+-0.3061^ definitely 1.9841x faster poly-stricteq-not-double-nor-string 16.6880+-0.2317 16.3627+-0.3729 might be 1.0199x faster poly-stricteq 49.2175+-0.6047 48.9532+-0.6758 I looked at how many cases of Untyped/Untyped compareStrictEq have been fixed by this patch and two other recent patches. On JetStream2: - https://bugs.webkit.org/show_bug.cgi?id=226621: 731 instances - https://bugs.webkit.org/show_bug.cgi?id=226676: 944 instances - This patch: only 26 instances This leaves 20 instances of Untyped/Untyped. On Speedometer2.0: - https://bugs.webkit.org/show_bug.cgi?id=226621: 1587 instances - https://bugs.webkit.org/show_bug.cgi?id=226676: 2784 instances - This patch: 891 instances This leaves 75 instances of Untyped/Untyped. * bytecode/SpeculatedType.h: (JSC::isNeitherDoubleNorHeapBigIntSpeculation): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNeitherDoubleNorHeapBigInt): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::emitBitwiseJSValueEquality): (JSC::DFG::SpeculativeJIT::emitBranchOnBitwiseJSValueEquality): (JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigInt): (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compileNeitherDoubleNorHeapBigIntToNotDoubleStrictEquality): * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::checkMayCrashIfInputIsEmpty): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): Modified Paths trunk/JSTests/ChangeLog trunk/JSTests/stress/reflect-set.js trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/bytecode/SpeculatedType.h trunk/Source/_javascript_Core/dfg/DFGDoesGC.cpp trunk/Source/_javascript_Core/dfg/DFGFixupPhase.cpp trunk/Source/_javascript_Core/dfg/DFGNode.h trunk/Source/_javascript_Core/dfg/DFGSafeToExecute.h trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.h trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp trunk/Source/_javascript_Core/dfg/DFGUseKind.cpp trunk/Source/_javascript_Core/dfg/DFGUseKind.h trunk/Source/_javascript_Core/ftl/FTLCapabilities.cpp trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp Diff Modified: trunk/JSTests/ChangeLog (282199 => 282200) --- trunk/JSTests/ChangeLog 2021-09-09 07:37:01 UTC (rev 282199) +++ trunk/JSTests/ChangeLog 2021-09-09 08:10:20 UTC (rev 282200) @@ -1,3 +1,17 @@ +2021-09-09 Robin Morisset + +Optimize compareStrictEq when neither side is a double and at least one is not a BigInt +https://bugs.webkit.org/show_bug.cgi?id=226755 + + +
[webkit-changes] [280704] trunk/Source/JavaScriptCore
Title: [280704] trunk/Source/_javascript_Core
Revision 280704
Author rmoris...@apple.com
Date 2021-08-05 15:39:57 -0700 (Thu, 05 Aug 2021)
Log Message
REGRESSION (r280507): ASSERTION FAILED: !undominatedPhis.contains(value) in JSC::B3::(anonymous namespace)::Validater::validatePhisAreDominatedByUpsilons()
https://bugs.webkit.org/show_bug.cgi?id=228838
Reviewed by Geoffrey Garen.
When I added validation of the dominance of Phis by their Upsilons, I checked two things:
- There is no path from the entry point to a Phi without going through a corresponding Upsilon (the actual dominance check)
- There is no way to execute a Phi twice without going through a corresponding Upsilon in between
The second property is not actually true in B3 IR, I had misunderstood that part of the meaning of Phis/Upsilons.
So this patch just removes this second check.
It has no security/stability/performance implication: this is validation code, which runs automatically in debug mode, but should not run at all on customer machines.
* b3/B3Validate.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3Validate.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (280703 => 280704)
--- trunk/Source/_javascript_Core/ChangeLog 2021-08-05 20:56:52 UTC (rev 280703)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-08-05 22:39:57 UTC (rev 280704)
@@ -1,3 +1,21 @@
+2021-08-05 Robin Morisset
+
+REGRESSION (r280507): ASSERTION FAILED: !undominatedPhis.contains(value) in JSC::B3::(anonymous namespace)::Validater::validatePhisAreDominatedByUpsilons()
+https://bugs.webkit.org/show_bug.cgi?id=228838
+
+
+Reviewed by Geoffrey Garen.
+
+When I added validation of the dominance of Phis by their Upsilons, I checked two things:
+- There is no path from the entry point to a Phi without going through a corresponding Upsilon (the actual dominance check)
+- There is no way to execute a Phi twice without going through a corresponding Upsilon in between
+The second property is not actually true in B3 IR, I had misunderstood that part of the meaning of Phis/Upsilons.
+So this patch just removes this second check.
+
+It has no security/stability/performance implication: this is validation code, which runs automatically in debug mode, but should not run at all on customer machines.
+
+* b3/B3Validate.cpp:
+
2021-08-05 Michael Catanzaro
GCC 11 builds should use -Wno-array-bounds, -Wno-nonnull
Modified: trunk/Source/_javascript_Core/b3/B3Validate.cpp (280703 => 280704)
--- trunk/Source/_javascript_Core/b3/B3Validate.cpp 2021-08-05 20:56:52 UTC (rev 280703)
+++ trunk/Source/_javascript_Core/b3/B3Validate.cpp 2021-08-05 22:39:57 UTC (rev 280704)
@@ -677,7 +677,6 @@
undominatedPhis.remove(value->as()->phi());
break;
case Phi:
-VALIDATE(!undominatedPhis.contains(value), ("At ", *value));
undominatedPhis.add(value);
break;
default:
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [280507] trunk
Title: [280507] trunk
Revision 280507
Author rmoris...@apple.com
Date 2021-07-30 18:40:05 -0700 (Fri, 30 Jul 2021)
Log Message
Improve OSR entry into Wasm loops with arguments
https://bugs.webkit.org/show_bug.cgi?id=228595
Reviewed by Yusuke Suzuki.
JSTests:
Just a straightforward test that counts to 1M in a loop, to exercise both OSR entry and a loop with an argument at the same time.
100k iterations was not enough to reliably complete an OSR entry.
* wasm/stress/osr-entry-with-loop-arguments.js: Added.
(async test):
Source/_javascript_Core:
This patch has two parts:
- improve the Wasm OSR code to fully support loop arguments (just some plumbing to make sure that the right values are propagated)
- improve the B3 validator to fix a hole I noticed while writing the first part: we were not detecting code that introduce Upsilons in the wrong blocks.
Naturally, this caused hard to debug issues, as B3 has no well-defined semantics for a Phi that is reached before the corresponding Upsilon(s).
* b3/B3Validate.cpp:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
(JSC::Wasm::AirIRGenerator::addLoop):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
(JSC::Wasm::B3IRGenerator::addLoop):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addLoop):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3Validate.cpp
trunk/Source/_javascript_Core/wasm/WasmAirIRGenerator.cpp
trunk/Source/_javascript_Core/wasm/WasmB3IRGenerator.cpp
trunk/Source/_javascript_Core/wasm/WasmLLIntGenerator.cpp
Added Paths
trunk/JSTests/wasm/stress/osr-entry-with-loop-arguments.js
Diff
Modified: trunk/JSTests/ChangeLog (280506 => 280507)
--- trunk/JSTests/ChangeLog 2021-07-31 01:36:50 UTC (rev 280506)
+++ trunk/JSTests/ChangeLog 2021-07-31 01:40:05 UTC (rev 280507)
@@ -1,3 +1,16 @@
+2021-07-30 Robin Morisset
+
+Improve OSR entry into Wasm loops with arguments
+https://bugs.webkit.org/show_bug.cgi?id=228595
+
+Reviewed by Yusuke Suzuki.
+
+Just a straightforward test that counts to 1M in a loop, to exercise both OSR entry and a loop with an argument at the same time.
+100k iterations was not enough to reliably complete an OSR entry.
+
+* wasm/stress/osr-entry-with-loop-arguments.js: Added.
+(async test):
+
2021-07-30 Tadeu Zagallo
putInlineFastReplacingStaticPropertyIfNeeded should handle custom values
Added: trunk/JSTests/wasm/stress/osr-entry-with-loop-arguments.js (0 => 280507)
--- trunk/JSTests/wasm/stress/osr-entry-with-loop-arguments.js (rev 0)
+++ trunk/JSTests/wasm/stress/osr-entry-with-loop-arguments.js 2021-07-31 01:40:05 UTC (rev 280507)
@@ -0,0 +1,29 @@
+import * as assert from '../assert.js';
+import { instantiate } from "../wabt-wrapper.js";
+
+let wat = `
+(module
+ (func (export "test") (param $countArg i32) (result i32) (local $result i32)
+i32.const 0
+(loop (param i32) (result i32)
+ i32.const 1
+ i32.add
+ local.tee $result
+ local.get $result
+ local.get $countArg
+ i32.lt_u
+ br_if 0
+)
+ )
+)
+`;
+
+async function test() {
+let instance = await instantiate(wat);
+
+let result = instance.exports.test(100);
+if (result !== 100)
+throw new Error("Expected 10, but got: " + result);
+}
+
+assert.asyncTest(test());
Modified: trunk/Source/_javascript_Core/ChangeLog (280506 => 280507)
--- trunk/Source/_javascript_Core/ChangeLog 2021-07-31 01:36:50 UTC (rev 280506)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-07-31 01:40:05 UTC (rev 280507)
@@ -1,3 +1,25 @@
+2021-07-30 Robin Morisset
+
+Improve OSR entry into Wasm loops with arguments
+https://bugs.webkit.org/show_bug.cgi?id=228595
+
+Reviewed by Yusuke Suzuki.
+
+This patch has two parts:
+- improve the Wasm OSR code to fully support loop arguments (just some plumbing to make sure that the right values are propagated)
+- improve the B3 validator to fix a hole I noticed while writing the first part: we were not detecting code that introduce Upsilons in the wrong blocks.
+ Naturally, this caused hard to debug issues, as B3 has no well-defined semantics for a Phi that is reached before the corresponding Upsilon(s).
+
+* b3/B3Validate.cpp:
+* wasm/WasmAirIRGenerator.cpp:
+(JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
+(JSC::Wasm::AirIRGenerator::addLoop):
+* wasm/WasmB3IRGenerator.cpp:
+(JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
+(JSC::Wasm::B3IRGenerator::addLoop):
+* wasm/WasmLLIntGenerator.cpp:
+(JSC::Wasm::LLIntGenerator::addLoop):
+
2021-07-30 Philip Chimento
[JSC] Rename Temporal.now to Temporal.Now
Modified: trunk/Source/_javascript_Core/b3/B3Validate.cpp (280506 => 280507)
---
[webkit-changes] [279903] trunk/Source/JavaScriptCore
Title: [279903] trunk/Source/_javascript_Core
Revision 279903
Author rmoris...@apple.com
Date 2021-07-13 20:21:03 -0700 (Tue, 13 Jul 2021)
Log Message
Invalid machine code emitted by SpeculativeJIT::emitObjectOrOtherBranch
https://bugs.webkit.org/show_bug.cgi?id=227869
Reviewed by Mark Lam.
SpeculativeJIT::emitObjectOrOtherBranch used to check the validity of the masqueradesAsUndefined watchpoint twice, and assumed that it could not change in between.
That is clearly incorrect as the main thread is running concurrently with it, and so the watchpoint could fire at any time.
The fix is trivial: just check the validity once, and store the result in a boolean.
If the watchpoint triggers later that is fine: we'll notice and cancel the compilation (see WatchpointCollectionPhase, Plan::isStillValid() and Plan::finalize()).
The change only protects us from rare and hard-to-reproduce crashes on debug builds caused by an ASSERT firing.
I did not add a testcase, as I can only reproduce the bug by adding an extra wait in the middle of emitObjectOrOtherBranch.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (279902 => 279903)
--- trunk/Source/_javascript_Core/ChangeLog 2021-07-14 02:42:10 UTC (rev 279902)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-07-14 03:21:03 UTC (rev 279903)
@@ -1,3 +1,22 @@
+2021-07-13 Robin Morisset
+
+Invalid machine code emitted by SpeculativeJIT::emitObjectOrOtherBranch
+https://bugs.webkit.org/show_bug.cgi?id=227869
+
+
+Reviewed by Mark Lam.
+
+SpeculativeJIT::emitObjectOrOtherBranch used to check the validity of the masqueradesAsUndefined watchpoint twice, and assumed that it could not change in between.
+That is clearly incorrect as the main thread is running concurrently with it, and so the watchpoint could fire at any time.
+The fix is trivial: just check the validity once, and store the result in a boolean.
+If the watchpoint triggers later that is fine: we'll notice and cancel the compilation (see WatchpointCollectionPhase, Plan::isStillValid() and Plan::finalize()).
+The change only protects us from rare and hard-to-reproduce crashes on debug builds caused by an ASSERT firing.
+
+I did not add a testcase, as I can only reproduce the bug by adding an extra wait in the middle of emitObjectOrOtherBranch.
+
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
+
2021-07-13 Yijia Huang
Add a new Air::Arg kind ZeroReg to let AIR recognise the new instructions/forms accepting zero register in ARM64
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp (279902 => 279903)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp 2021-07-14 02:42:10 UTC (rev 279902)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp 2021-07-14 03:21:03 UTC (rev 279903)
@@ -1986,7 +1986,8 @@
GPRReg scratchGPR = scratch.gpr();
GPRReg structureGPR = InvalidGPRReg;
-if (!masqueradesAsUndefinedWatchpointIsStillValid()) {
+bool objectMayMasqueradeAsUndefined = !masqueradesAsUndefinedWatchpointIsStillValid();
+if (objectMayMasqueradeAsUndefined) {
GPRTemporary realStructure(this);
structure.adopt(realStructure);
structureGPR = structure.gpr();
@@ -1993,7 +1994,7 @@
}
MacroAssembler::Jump notCell = m_jit.branchIfNotCell(JSValueRegs(valueGPR));
-if (masqueradesAsUndefinedWatchpointIsStillValid()) {
+if (!objectMayMasqueradeAsUndefined) {
DFG_TYPE_CHECK(
JSValueRegs(valueGPR), nodeUse, (~SpecCellCheck) | SpecObject, m_jit.branchIfNotObject(valueGPR));
} else {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [279560] trunk/Source/JavaScriptCore
Title: [279560] trunk/Source/_javascript_Core
Revision 279560
Author rmoris...@apple.com
Date 2021-07-04 16:55:48 -0700 (Sun, 04 Jul 2021)
Log Message
ActiveScratchBufferScope should take the buffer as argument
https://bugs.webkit.org/show_bug.cgi?id=227670
rdar://80011612
Reviewed by Mark Lam.
https://bugs.webkit.org/show_bug.cgi?id=227013 created ActiveScratchBufferScope.
It is used by operations that can cause the GC to run, to mark as roots the contents of the scratch buffer that is live during that time (if any).
The bug is that it simply asks the VM for a scratch buffer of the right size, but this will always return the last scratch buffer, and not necessarily the one that the operation is actually using.
A fairly simple fix is to pass it directly the scratch buffer, since the operation normally can get it easily enough.
In most cases the operation has access to the m_buffer field of the ScratchBuffer, but getting a pointer to the entire structure from that is fairly simple (I added ScratchBuffer::fromData() to do so).
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOSRExit.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewArray):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::haveABadTime):
* runtime/VM.h:
(JSC::ScratchBuffer::fromData):
* runtime/VMInlines.h:
(JSC::ActiveScratchBufferScope::ActiveScratchBufferScope):
(JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGOSRExit.cpp
trunk/Source/_javascript_Core/dfg/DFGOSRExit.h
trunk/Source/_javascript_Core/dfg/DFGOperations.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGThunks.cpp
trunk/Source/_javascript_Core/runtime/VM.h
trunk/Source/_javascript_Core/runtime/VMInlines.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (279559 => 279560)
--- trunk/Source/_javascript_Core/ChangeLog 2021-07-04 21:06:12 UTC (rev 279559)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-07-04 23:55:48 UTC (rev 279560)
@@ -1,3 +1,35 @@
+2021-07-04 Robin Morisset
+
+ActiveScratchBufferScope should take the buffer as argument
+https://bugs.webkit.org/show_bug.cgi?id=227670
+rdar://80011612
+
+Reviewed by Mark Lam.
+
+https://bugs.webkit.org/show_bug.cgi?id=227013 created ActiveScratchBufferScope.
+It is used by operations that can cause the GC to run, to mark as roots the contents of the scratch buffer that is live during that time (if any).
+The bug is that it simply asks the VM for a scratch buffer of the right size, but this will always return the last scratch buffer, and not necessarily the one that the operation is actually using.
+
+A fairly simple fix is to pass it directly the scratch buffer, since the operation normally can get it easily enough.
+In most cases the operation has access to the m_buffer field of the ScratchBuffer, but getting a pointer to the entire structure from that is fairly simple (I added ScratchBuffer::fromData() to do so).
+
+* dfg/DFGOSRExit.cpp:
+(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
+* dfg/DFGOSRExit.h:
+* dfg/DFGOperations.cpp:
+(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compileNewArray):
+* dfg/DFGThunks.cpp:
+(JSC::DFG::osrExitGenerationThunkGenerator):
+* runtime/JSGlobalObject.cpp:
+(JSC::JSGlobalObject::haveABadTime):
+* runtime/VM.h:
+(JSC::ScratchBuffer::fromData):
+* runtime/VMInlines.h:
+(JSC::ActiveScratchBufferScope::ActiveScratchBufferScope):
+(JSC::ActiveScratchBufferScope::~ActiveScratchBufferScope):
+
2021-07-04 Alexey Shvayka
[WebIDL] Simplify generation of runtime conditionally read-write attributes
Modified: trunk/Source/_javascript_Core/dfg/DFGOSRExit.cpp (279559 => 279560)
--- trunk/Source/_javascript_Core/dfg/DFGOSRExit.cpp 2021-07-04 21:06:12 UTC (rev 279559)
+++ trunk/Source/_javascript_Core/dfg/DFGOSRExit.cpp 2021-07-04 23:55:48 UTC (rev 279560)
@@ -141,11 +141,11 @@
}
}
-JSC_DEFINE_JIT_OPERATION(operationCompileOSRExit, void, (CallFrame* callFrame))
+JSC_DEFINE_JIT_OPERATION(operationCompileOSRExit, void, (CallFrame* callFrame, void* bufferToPreserve))
{
VM& vm = callFrame->deprecatedVM();
auto scope = DECLARE_THROW_SCOPE(vm);
-ActiveScratchBufferScope activeScratchBufferScope(vm, GPRInfo::numberOfRegisters + FPRInfo::numberOfRegisters);
+ActiveScratchBufferScope activeScratchBufferScope(ScratchBuffer::fromData(bufferToPreserve), GPRInfo::numberOfRegisters + FPRInfo::numberOfRegisters);
if constexpr (validateDFGDoesGC) {
// We're about to exit optimized
[webkit-changes] [279052] trunk/Source/JavaScriptCore
Title: [279052] trunk/Source/_javascript_Core
Revision 279052
Author rmoris...@apple.com
Date 2021-06-20 00:37:12 -0700 (Sun, 20 Jun 2021)
Log Message
Fix speculated type in the one-argument overload of speculateNeitherDoubleNorHeapBigIntNorString
https://bugs.webkit.org/show_bug.cgi?id=227119
Reviewed by Yusuke Suzuki.
Same problem as bug 226786: a missing check for HeapBigInt in the speculateNeitherDoubleNorHeapBigIntNorString function introduced in 226676.
I also rewrote the SpeculatedType for NeitherDoubleNorHeapBigIntNorString in typeFilterFor for readability. The old and the new SpeculatedType are perfectly identical, it is just a different (and in my view more readable) way of writing it.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGUseKind.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (279051 => 279052)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-20 02:05:08 UTC (rev 279051)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-20 07:37:12 UTC (rev 279052)
@@ -1,3 +1,19 @@
+2021-06-20 Robin Morisset
+
+Fix speculated type in the one-argument overload of speculateNeitherDoubleNorHeapBigIntNorString
+https://bugs.webkit.org/show_bug.cgi?id=227119
+
+Reviewed by Yusuke Suzuki.
+
+Same problem as bug 226786: a missing check for HeapBigInt in the speculateNeitherDoubleNorHeapBigIntNorString function introduced in 226676.
+
+I also rewrote the SpeculatedType for NeitherDoubleNorHeapBigIntNorString in typeFilterFor for readability. The old and the new SpeculatedType are perfectly identical, it is just a different (and in my view more readable) way of writing it.
+
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
+* dfg/DFGUseKind.h:
+(JSC::DFG::typeFilterFor):
+
2021-06-19 Mark Lam
[Revert r278576] Put the Baseline JIT prologue and op_loop_hint code in JIT thunks.
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (279051 => 279052)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-06-20 02:05:08 UTC (rev 279051)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-06-20 07:37:12 UTC (rev 279052)
@@ -11726,7 +11726,7 @@
void SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString(Edge edge)
{
-if (!needsTypeCheck(edge, ~(SpecFullDouble | SpecString)))
+if (!needsTypeCheck(edge, ~(SpecFullDouble | SpecHeapBigInt | SpecString)))
return;
JSValueOperand operand(this, edge, ManualOperandSpeculation);
Modified: trunk/Source/_javascript_Core/dfg/DFGUseKind.h (279051 => 279052)
--- trunk/Source/_javascript_Core/dfg/DFGUseKind.h 2021-06-20 02:05:08 UTC (rev 279051)
+++ trunk/Source/_javascript_Core/dfg/DFGUseKind.h 2021-06-20 07:37:12 UTC (rev 279052)
@@ -192,7 +192,7 @@
case NotDoubleUse:
return ~SpecFullDouble;
case NeitherDoubleNorHeapBigIntNorStringUse:
-return ~SpecFullDouble & ~SpecHeapBigInt & ~SpecString;
+return ~(SpecFullDouble | SpecHeapBigInt | SpecString);
case KnownOtherUse:
case OtherUse:
return SpecOther;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [279041] trunk/Source/JavaScriptCore
Title: [279041] trunk/Source/_javascript_Core
Revision 279041
Author rmoris...@apple.com
Date 2021-06-18 10:17:45 -0700 (Fri, 18 Jun 2021)
Log Message
[DFG] Untyped branches should eliminate checks based on results from the AbstractInterpreter
https://bugs.webkit.org/show_bug.cgi?id=227159
Reviewed by Filip Pizlo.
We currently emit a ton of code for Untyped branches, as we use branchIfTruthy which does not know anything about the abstract interpreter.
Even worse: we call branchIfTruthy after emitting some fast paths, and branchIfTruthy replicates these fast paths (Int32 and Booleans).
While I plan to reduce the number of Untyped branches in some separate patches, there is a very long tail of predicted types visible in benchmarks, so I expect some of them to remain no matter what, justifying making the code emitted in that case more reasonable.
The implementation in this patch is fairly straightforward, as it follows very closely branchOnValue() from AssemblyHelpers (which was previously called through branchIfTruthy).
It was tested on the JSC stress tests, as well as on JetStream2.
On JetStream2, it reduced the average number of bytes emitted for Branch by the DFG from 30.1 to 27.5 (highly significant, it only changes by about 0.1 between runs).
Since only about 1.5k branches are untyped out of 34k in that benchmark, it means that this patch reduces the amount of code emitted for untyped branches by about 50 bytes on average.
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::branchDoubleZeroOrNaN):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitUntypedBranch):
(JSC::DFG::SpeculativeJIT::emitBranch):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (279040 => 279041)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-18 16:45:42 UTC (rev 279040)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-18 17:17:45 UTC (rev 279041)
@@ -1,3 +1,27 @@
+2021-06-18 Robin Morisset
+
+[DFG] Untyped branches should eliminate checks based on results from the AbstractInterpreter
+https://bugs.webkit.org/show_bug.cgi?id=227159
+
+Reviewed by Filip Pizlo.
+
+We currently emit a ton of code for Untyped branches, as we use branchIfTruthy which does not know anything about the abstract interpreter.
+Even worse: we call branchIfTruthy after emitting some fast paths, and branchIfTruthy replicates these fast paths (Int32 and Booleans).
+While I plan to reduce the number of Untyped branches in some separate patches, there is a very long tail of predicted types visible in benchmarks, so I expect some of them to remain no matter what, justifying making the code emitted in that case more reasonable.
+
+The implementation in this patch is fairly straightforward, as it follows very closely branchOnValue() from AssemblyHelpers (which was previously called through branchIfTruthy).
+
+It was tested on the JSC stress tests, as well as on JetStream2.
+
+On JetStream2, it reduced the average number of bytes emitted for Branch by the DFG from 30.1 to 27.5 (highly significant, it only changes by about 0.1 between runs).
+Since only about 1.5k branches are untyped out of 34k in that benchmark, it means that this patch reduces the amount of code emitted for untyped branches by about 50 bytes on average.
+
+* dfg/DFGSpeculativeJIT.h:
+(JSC::DFG::SpeculativeJIT::branchDoubleZeroOrNaN):
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::emitUntypedBranch):
+(JSC::DFG::SpeculativeJIT::emitBranch):
+
2021-06-17 Mark Lam
Rename numberOfPACBits to maxNumberOfAllowedPACBits.
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.h (279040 => 279041)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.h 2021-06-18 16:45:42 UTC (rev 279040)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.h 2021-06-18 17:17:45 UTC (rev 279041)
@@ -1110,6 +1110,11 @@
{
return addBranch(m_jit.branchDoubleNonZero(value, scratch), destination);
}
+
+void branchDoubleZeroOrNaN(FPRReg value, FPRReg scratch, BasicBlock* destination)
+{
+return addBranch(m_jit.branchDoubleZeroOrNaN(value, scratch), destination);
+}
template
void branch32(JITCompiler::RelationalCondition cond, T left, U right, BasicBlock* destination)
@@ -1245,6 +1250,7 @@
void emitObjectOrOtherBranch(Edge value, BasicBlock* taken, BasicBlock* notTaken);
void emitStringBranch(Edge value, BasicBlock* taken, BasicBlock* notTaken);
void emitStringOrOtherBranch(Edge value, BasicBlock* taken, BasicBlock* notTaken);
+void emitUntypedBranch(Edge value, BasicBlock* taken, BasicBlock* notTaken);
void emitBranch(Node*);
struct StringSwitchCase {
Modified:
[webkit-changes] [278959] trunk/Source/JavaScriptCore
Title: [278959] trunk/Source/_javascript_Core
Revision 278959
Author rmoris...@apple.com
Date 2021-06-16 15:26:31 -0700 (Wed, 16 Jun 2021)
Log Message
Don't look at the (non-existent) child2 of DelById
https://bugs.webkit.org/show_bug.cgi?id=227095
Reviewed by Mark Lam.
Trivial fix to a broken rebase: while it is ok to share most code between DelById and DelByVal, only the latter has a child2(), so it should not be accessed if we are compiling the former.
No new test, as it was caught by one of our existing tests.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (278958 => 278959)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-16 22:22:06 UTC (rev 278958)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-16 22:26:31 UTC (rev 278959)
@@ -1,3 +1,16 @@
+2021-06-16 Robin Morisset
+
+Don't look at the (non-existent) child2 of DelById
+https://bugs.webkit.org/show_bug.cgi?id=227095
+
+Reviewed by Mark Lam.
+
+Trivial fix to a broken rebase: while it is ok to share most code between DelById and DelByVal, only the latter has a child2(), so it should not be accessed if we are compiling the former.
+No new test, as it was caught by one of our existing tests.
+
+* ftl/FTLLowerDFGToB3.cpp:
+(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
+
2021-06-16 Yijia Huang
Add Air opcode sub32/64(Reg, Imm, Reg) form for ARM64 and select this instruction in Air
Modified: trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp (278958 => 278959)
--- trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp 2021-06-16 22:22:06 UTC (rev 278958)
+++ trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp 2021-06-16 22:26:31 UTC (rev 278959)
@@ -5917,8 +5917,10 @@
State* state = _ftlState;
Node* node = m_node;
CodeOrigin nodeSemanticOrigin = node->origin.semantic;
-auto child1UseKind = node->child1().useKind();
-auto child2UseKind = node->child2().useKind();
+UseKind child1UseKind = node->child1().useKind();
+UseKind child2UseKind = UntypedUse;
+if constexpr (kind != DelByKind::ById)
+child2UseKind = node->child2().useKind();
auto ecmaMode = node->ecmaMode().value();
patchpoint->setGenerator(
[=] (CCallHelpers& jit, const StackmapGenerationParams& params) {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [278945] trunk/Source/JavaScriptCore
Title: [278945] trunk/Source/_javascript_Core Revision 278945 Author rmoris...@apple.com Date 2021-06-16 11:34:23 -0700 (Wed, 16 Jun 2021) Log Message Drop the FTL(DFG) graph after lowering to B3 https://bugs.webkit.org/show_bug.cgi?id=226556 Reviewed by Phil Pizlo. This patch originally landed as r278463, was reverted in r278463. I believe that the bug for which it was reverted actually comes from r278371, which was also reverted at the same time. So I am now relanding this. The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed. In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node. The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way. We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later emit the required code in a vector, and capture that vector in the lambda (through a move capture, which is allowed since C++14). See `struct VarargsSpreadArgumentToEmit` for the information that we need to store in that vector. I tested this change by completing a full run of JetStream2 with ASAN. I also ran the stress tests with "spread" in their name in Debug mode. * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::freeDFGIRAfterLowering): * dfg/DFGGraph.h: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::getPrivateName): (JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess): (JSC::FTL::DFG::LowerDFGToB3::cachedPutById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::VarargsSpreadArgumentToEmit::VarargsSpreadArgumentToEmit): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::compileInById): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet): (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet): (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet): (JSC::FTL::DFG::LowerDFGToB3::crash): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/dfg/DFGGraph.cpp trunk/Source/_javascript_Core/dfg/DFGGraph.h trunk/Source/_javascript_Core/ftl/FTLCompile.cpp trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp trunk/Source/_javascript_Core/ftl/FTLSnippetParams.cpp trunk/Source/_javascript_Core/ftl/FTLSnippetParams.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (278944 => 278945) --- trunk/Source/_javascript_Core/ChangeLog 2021-06-16 18:26:43 UTC (rev 278944) +++ trunk/Source/_javascript_Core/ChangeLog 2021-06-16 18:34:23 UTC (rev 278945) @@ -1,3 +1,52 @@ +2021-06-16 Robin Morisset + +Drop the FTL(DFG) graph after lowering to B3 +https://bugs.webkit.org/show_bug.cgi?id=226556 + +Reviewed by Phil Pizlo. + +This patch originally landed as r278463, was reverted in r278463. +I believe that the bug for which it was reverted actually comes from r278371, which was also reverted at the same time. So I am now relanding this. + +The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed. +In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node. +The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way. +We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later
[webkit-changes] [278810] trunk/Source/JavaScriptCore
Title: [278810] trunk/Source/_javascript_Core Revision 278810 Author rmoris...@apple.com Date 2021-06-12 10:17:27 -0700 (Sat, 12 Jun 2021) Log Message We should drop B3 values while running Air https://bugs.webkit.org/show_bug.cgi?id=226187 Reviewed by Saam Barati. NB: this patch first landed as r278371, then was reverted in r278587 as it broke --dumpDisassembly(). I fixed the bug (a missing line setDisassembler()) and am now re-landing it. Below is a copy of the original Changelog. We must keep the following values: - WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument. - CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of itsorigin. I intend to fix these in later patches if possible. Finally we must preserve all B3 values in the following cases: - if we dump the disassembly or the Air graph: because otherwise we cannot print the origins - if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins. We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments. We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State. Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise). The performance impact of this is a progression on various RAMification subtests on Mac, but is more mitigated on iPhone7, with various regressions. I suspect these to be noise, and will monitor the performance bots post-landing to make sure of it. * b3/B3LowerToAir.cpp: (JSC::B3::lowerToAir): * b3/B3Procedure.cpp: (JSC::B3::Procedure::freeUnneededB3ValuesAfterLowering): * b3/B3Procedure.h: (JSC::B3::Procedure::releasePCToOriginMap): (JSC::B3::Procedure::setNeedsPCToOriginMap): (JSC::B3::Procedure::needsPCToOriginMap): * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): (JSC::B3::SparseCollection::filterAndTransfer): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * b3/air/AirCode.h: (JSC::B3::Air::Code::shouldPreserveB3Origins const): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generateWithAlreadyAllocatedRegisters): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLState.cpp: (JSC::FTL::State::State): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/B3Generate.cpp trunk/Source/_javascript_Core/b3/B3PCToOriginMap.h trunk/Source/_javascript_Core/b3/B3Procedure.cpp trunk/Source/_javascript_Core/b3/B3Procedure.h trunk/Source/_javascript_Core/b3/B3SparseCollection.h trunk/Source/_javascript_Core/b3/air/AirCode.cpp trunk/Source/_javascript_Core/b3/air/AirCode.h trunk/Source/_javascript_Core/b3/air/AirGenerate.cpp trunk/Source/_javascript_Core/b3/testb3_6.cpp trunk/Source/_javascript_Core/ftl/FTLCompile.cpp trunk/Source/_javascript_Core/ftl/FTLState.cpp Diff Modified: trunk/Source/_javascript_Core/ChangeLog (278809 => 278810) --- trunk/Source/_javascript_Core/ChangeLog 2021-06-12 07:26:33 UTC (rev 278809) +++ trunk/Source/_javascript_Core/ChangeLog 2021-06-12 17:17:27 UTC (rev 278810) @@ -1,3 +1,52 @@ +2021-06-12 Robin Morisset + +We should drop B3 values while running Air +https://bugs.webkit.org/show_bug.cgi?id=226187 + +Reviewed by Saam Barati. + +NB: this patch first landed as r278371, then was reverted in r278587 as it broke --dumpDisassembly(). +I fixed the bug (a missing line setDisassembler()) and am now re-landing it. Below is a copy of the original Changelog. + +We must keep the following values: +- WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument. +- CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of itsorigin. +I intend to fix these in later patches if possible. + +Finally we must preserve all B3 values in the following cases: +- if we dump the disassembly or the Air graph: because otherwise we cannot print the origins +- if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins. + +We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments. +We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State. + +Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise). + +The performance impact of this is a progression on various RAMification subtests on
[webkit-changes] [278642] trunk/Source/JavaScriptCore
Title: [278642] trunk/Source/_javascript_Core
Revision 278642
Author rmoris...@apple.com
Date 2021-06-08 19:32:47 -0700 (Tue, 08 Jun 2021)
Log Message
Fix speculated type in speculateNeitherDoubleNorHeapBigIntNorString
https://bugs.webkit.org/show_bug.cgi?id=226786
Reviewed by Mark Lam.
I had forgotten the HeapBigInt part.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (278641 => 278642)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-09 02:26:34 UTC (rev 278641)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-09 02:32:47 UTC (rev 278642)
@@ -1,3 +1,15 @@
+2021-06-08 Robin Morisset
+
+Fix speculated type in speculateNeitherDoubleNorHeapBigIntNorString
+https://bugs.webkit.org/show_bug.cgi?id=226786
+
+Reviewed by Mark Lam.
+
+I had forgotten the HeapBigInt part.
+
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString):
+
2021-06-06 Yusuke Suzuki
[JSC] Use ResolvedClosureVar to get brand from scope
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (278641 => 278642)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-06-09 02:26:34 UTC (rev 278641)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2021-06-09 02:32:47 UTC (rev 278642)
@@ -11565,7 +11565,7 @@
void SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString(Edge edge, JSValueRegs regs, GPRReg tempGPR)
{
-if (!needsTypeCheck(edge, ~(SpecFullDouble | SpecString)))
+if (!needsTypeCheck(edge, ~(SpecFullDouble | SpecString | SpecHeapBigInt)))
return;
MacroAssembler::JumpList done;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [278568] trunk
Title: [278568] trunk Revision 278568 Author rmoris...@apple.com Date 2021-06-07 12:55:30 -0700 (Mon, 07 Jun 2021) Log Message Optimize compareStrictEq when neither side is a double and at least one is neither a string nor a BigInt https://bugs.webkit.org/show_bug.cgi?id=226676 Reviewed by Filip Pizlo. JSTests: I made two variants of the already existing poly-stricteq microbenchmarks with different types in the array. I also tweaked all three so that we more reliably reach the FTL. Finally I added a stress-test to verify that I did not introduce an OSR exit bug. * microbenchmarks/poly-stricteq-not-double-nor-string.js: Added. (foo): (test): * microbenchmarks/poly-stricteq-not-double.js: Added. (foo): (test): * microbenchmarks/poly-stricteq.js: (foo): (test): * stress/poly-stricteq-not-double-nor-string-fail.js: Added. (foo): (test): Source/_javascript_Core: There is exactly one case where x === y must return false despite x and y being JSValues with the same bits: NaN === NaN There are a few cases where x === y must return true despite x and y being JSValues with potentially different bits: Double === Int32 String === String HeapBigInt === HeapBigInt HeapBigInt === BigInt32 (if they are enabled) If we don't have a double on either side, at least one side has neither a String nor a HeapBigInt, and BigInt32 are disabled, we can clearly ignore all of these pathological cases. This optimization was decided based on looking at DFG graphs of Speedometer2; here is a sample of the compareStrictEq(Untyped, Untyped), courtesy of Phil: Final|Array|String|Bool, Final|Array|String|Bool Array|String|Bool, String|Bool (twice) Array|String|Bool, String|Int32 (once in DFG, once in FTL) ! Array|String|Bool, Array|Bool ! Final|Other, Final|Other ! Int32|Other, Int32 Final|StringIdent, Final|StringIdent (3 times) Final|StringIdent|BoolInt32, StringIdent|BoolInt32 (twice) String|Bool, String|Bool (4 times) DoublePureNaN, String|Bool ! Other, Function|Other ! Final|Other, Final|Function|Other (twice) Final|String|Bool|Other, Final|String|Bool|Other (3 times, two in the FTL) Final|String|Int32, String|Int32 (four times) String|Int32|Bool, Function|String|Int32|Bool (twice) String|DoublePureNaN, String|Bool (twice) ! Final|Bool|Other, Final|Function|Other (four times, twice in FTL) I marked with a ! those for which this optimization should apply. The only slightly interesting part of this patch is DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString where I took care to skip every test whose result we can predict from the abstract interpreter. Results on microbenchmarks: poly-stricteq-not-double 45.5793+-0.5304 ? 46.0306+-0.5621? poly-stricteq-not-double-nor-string 45.5829+-0.5750 ^ 16.9089+-0.3070^ definitely 2.6958x faster poly-stricteq 49.9719+-0.6450 48.9855+-0.5227 might be 1.0201x faster I also measured the amount of code that we generate in the DFG on JetStream2. The results here are disappointing but still measurable. Before: DFG_fast_CompareStrictEq totalBytes: 468425 count: 10951 avg: 42.774632 DFG_fast_CompareStrictEq totalBytes: 468020 count: 10917 avg: 42.870752 DFG_fast_CompareStrictEq totalBytes: 467424 count: 10888 avg: 42.930198 After: DFG_fast_CompareStrictEq totalBytes: 463946 count: 10917 avg: 42.497573 DFG_fast_CompareStrictEq totalBytes: 474492 count: 11138 avg: 42.601185 DFG_fast_CompareStrictEq totalBytes: 467138 count: 10970 avg: 42.583227 * bytecode/SpeculatedType.h: (JSC::isNeitherDoubleNorHeapBigIntNorStringSpeculation): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue): * dfg/DFGNode.h: (JSC::DFG::Node::shouldSpeculateNeitherDoubleNorHeapBigIntNorString): * dfg/DFGSafeToExecute.h: (JSC::DFG::SafeToExecuteEdge::operator()): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileStrictEq): (JSC::DFG::SpeculativeJIT::compileNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::compilePeepHoleNotDoubleNeitherDoubleNorHeapBigIntNorStringStrictEquality): (JSC::DFG::SpeculativeJIT::speculateNotDouble): (JSC::DFG::SpeculativeJIT::speculateNeitherDoubleNorHeapBigIntNorString): (JSC::DFG::SpeculativeJIT::speculate): * dfg/DFGSpeculativeJIT.h: * dfg/DFGUseKind.cpp: (WTF::printInternal): * dfg/DFGUseKind.h: (JSC::DFG::typeFilterFor): (JSC::DFG::checkMayCrashIfInputIsEmpty): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq): (JSC::FTL::DFG::LowerDFGToB3::speculate): (JSC::FTL::DFG::LowerDFGToB3::speculateNeitherDoubleNorHeapBigIntNorString): Modified Paths trunk/JSTests/ChangeLog trunk/JSTests/microbenchmarks/poly-stricteq.js trunk/Source/_javascript_Core/ChangeLog
[webkit-changes] [278463] trunk/Source/JavaScriptCore
Title: [278463] trunk/Source/_javascript_Core Revision 278463 Author rmoris...@apple.com Date 2021-06-04 09:04:35 -0700 (Fri, 04 Jun 2021) Log Message Drop the FTL(DFG) graph after lowering to B3 https://bugs.webkit.org/show_bug.cgi?id=226556 Reviewed by Phil Pizlo. The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed. In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node. The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way. We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later emit the required code in a vector, and capture that vector in the lambda (through a move capture, which is allowed since C++14). See `struct VarargsSpreadArgumentToEmit` for the information that we need to store in that vector. I tested this change by completing a full run of JetStream2 with ASAN. I also ran the stress tests with "spread" in their name in Debug mode. * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::freeDFGIRAfterLowering): * dfg/DFGGraph.h: * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC): (JSC::FTL::DFG::LowerDFGToB3::getPrivateName): (JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess): (JSC::FTL::DFG::LowerDFGToB3::cachedPutById): (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal): (JSC::FTL::DFG::LowerDFGToB3::compileDelBy): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct): (JSC::FTL::DFG::LowerDFGToB3::compileTailCall): (JSC::FTL::DFG::LowerDFGToB3::VarargsSpreadArgumentToEmit::VarargsSpreadArgumentToEmit): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread): (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs): (JSC::FTL::DFG::LowerDFGToB3::compileCallEval): (JSC::FTL::DFG::LowerDFGToB3::compileInById): (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf): (JSC::FTL::DFG::LowerDFGToB3::getById): (JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis): (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet): (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet): (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet): (JSC::FTL::DFG::LowerDFGToB3::crash): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/dfg/DFGGraph.cpp trunk/Source/_javascript_Core/dfg/DFGGraph.h trunk/Source/_javascript_Core/ftl/FTLCompile.cpp trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp trunk/Source/_javascript_Core/ftl/FTLSnippetParams.cpp trunk/Source/_javascript_Core/ftl/FTLSnippetParams.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (278462 => 278463) --- trunk/Source/_javascript_Core/ChangeLog 2021-06-04 15:58:13 UTC (rev 278462) +++ trunk/Source/_javascript_Core/ChangeLog 2021-06-04 16:04:35 UTC (rev 278463) @@ -1,3 +1,49 @@ +2021-06-04 Robin Morisset + +Drop the FTL(DFG) graph after lowering to B3 +https://bugs.webkit.org/show_bug.cgi?id=226556 + +Reviewed by Phil Pizlo. + +The challenge in this patch was dealing with all of the Patchpoints created by FTLLowerDFGToB3: they get a lambda at that time, which they execute at the end of Air, and many of these lambdas were capturing a pointer to some parts of the DFG graph and reading through it when being executed. +In all cases but one it was easily fixed: they were only reading a few bits from a given node, so I just read these bits in FTLLowerDFGToB3, and captured them (by value) instead of the pointer to the node. +The exception was compileCallOrConstructVarargsSpread(): its patchpoint generator was walking through the graph, flattening a tree of PhantomSpread/PhantomNewArrayWithSpread/PhantomNewArrayBuffer/PhantomCreateRest, emitting some code along the way. +We now do this flattening of the tree in FTLLowerDFGToB3, store just enough information to later emit the required code in a vector, and capture that vector in the lambda (through a move capture, which is allowed since C++14). See `struct VarargsSpreadArgumentToEmit` for the information that we need to store in that vector. + +I tested this change by completing a full run of JetStream2 with ASAN. +I also ran the stress tests with "spread" in their name in Debug mode. + +* b3/B3SparseCollection.h: +
[webkit-changes] [278390] trunk/Source/JavaScriptCore
Title: [278390] trunk/Source/_javascript_Core
Revision 278390
Author rmoris...@apple.com
Date 2021-06-02 18:07:45 -0700 (Wed, 02 Jun 2021)
Log Message
B3MoveConstants should filter directly on Values, and only create ValueKeys when useful
https://bugs.webkit.org/show_bug.cgi?id=226420
Reviewed by Phil Pizlo.
I did a few runs of JetStream2 to measure results, the time spent in B3MoveConstants goes from 160-180ms to 100-110ms.
The total time spent in B3+Air is in the 6 to 8s range, so this is approximately a 1% speedup.
* b3/B3MoveConstants.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3MoveConstants.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (278389 => 278390)
--- trunk/Source/_javascript_Core/ChangeLog 2021-06-03 00:33:35 UTC (rev 278389)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-06-03 01:07:45 UTC (rev 278390)
@@ -1,5 +1,17 @@
2021-06-02 Robin Morisset
+B3MoveConstants should filter directly on Values, and only create ValueKeys when useful
+https://bugs.webkit.org/show_bug.cgi?id=226420
+
+Reviewed by Phil Pizlo.
+
+I did a few runs of JetStream2 to measure results, the time spent in B3MoveConstants goes from 160-180ms to 100-110ms.
+The total time spent in B3+Air is in the 6 to 8s range, so this is approximately a 1% speedup.
+
+* b3/B3MoveConstants.cpp:
+
+2021-06-02 Robin Morisset
+
Merge B3::StackSlot and Air::StackSlot
https://bugs.webkit.org/show_bug.cgi?id=226362
Modified: trunk/Source/_javascript_Core/b3/B3MoveConstants.cpp (278389 => 278390)
--- trunk/Source/_javascript_Core/b3/B3MoveConstants.cpp 2021-06-03 00:33:35 UTC (rev 278389)
+++ trunk/Source/_javascript_Core/b3/B3MoveConstants.cpp 2021-06-03 01:07:45 UTC (rev 278390)
@@ -51,15 +51,15 @@
void run()
{
hoistConstants(
-[&] (const ValueKey& key) -> bool {
-return key.opcode() == ConstFloat || key.opcode() == ConstDouble;
+[&] (const Value* value) -> bool {
+return value->opcode() == ConstFloat || value->opcode() == ConstDouble;
});
lowerFPConstants();
hoistConstants(
-[&] (const ValueKey& key) -> bool {
-return key.opcode() == Const32 || key.opcode() == Const64 || key.opcode() == ArgumentReg;
+[&] (const Value* value) -> bool {
+return value->opcode() == Const32 || value->opcode() == Const64 || value->opcode() == ArgumentReg;
});
}
@@ -75,10 +75,10 @@
for (BasicBlock* block : m_proc) {
for (Value* value : *block) {
for (Value*& child : value->children()) {
-ValueKey key = child->key();
-if (!filter(key))
+if (!filter(child))
continue;
+ValueKey key = child->key();
auto result = valueForConstant.add(key, child);
if (result.isNewEntry) {
// Assume that this block is where we want to materialize the value.
@@ -115,10 +115,10 @@
// ones from the CFG, since we're going to reinsert them elsewhere.
for (BasicBlock* block : m_proc) {
for (Value*& value : *block) {
-ValueKey key = value->key();
-if (!filter(key))
+if (!filter(value))
continue;
+ValueKey key = value->key();
if (valueForConstant.get(key) == value)
value = m_proc.add(Nop, value->origin());
else
@@ -153,13 +153,12 @@
// we have computed that the constant should be materialized in this block, but we
// haven't inserted it yet. This inserts the constant if necessary.
auto materialize = [&] (Value* child) {
-ValueKey key = child->key();
-if (!filter(key))
+if (!filter(child))
return;
// If we encounter a fast constant, then it must be canonical, since we already
// got rid of the non-canonical ones.
-ASSERT(valueForConstant.get(key) == child);
+ASSERT(valueForConstant.get(child->key()) == child);
if (child->owner != block) {
// This constant isn't our problem. It's going to be materialized in another
@@ -175,7 +174,7 @@
if (MemoryValue* memoryValue = value->as()) {
Value* pointer = memoryValue->lastChild();
-if (pointer->hasIntPtr() && filter(pointer->key())) {
+if (pointer->hasIntPtr() && filter(pointer)) {
auto desiredOffset = [&] (Value* otherPointer) -> intptr_t {
[webkit-changes] [278381] trunk/Source/JavaScriptCore
Title: [278381] trunk/Source/_javascript_Core Revision 278381 Author rmoris...@apple.com Date 2021-06-02 16:28:30 -0700 (Wed, 02 Jun 2021) Log Message Merge B3::StackSlot and Air::StackSlot https://bugs.webkit.org/show_bug.cgi?id=226362 Reviewed by Filip Pizlo. This is a very simple and safe (although small) memory saving, since every B3StackSlot eventually becomes an AirStackSlot with an exact copy of all the same information. Simply dropping the B3StackSlot past that point is tricky, because one of them might be retained by FTLState (and modified by Air). It is much simpler to just use Air::StackSlot throughout. It saves us: - 16 bytes per B3StackSlot (for the structure itself) - another 8 bytes per B3StackSlot (for the pointer in the SparseCollection) - 8 bytes per AirStackSlot (for the pointer to the B3::StackSlot) I also took the opportunity to save an extra 8 bytes per AirStackSlot, by shrinking the bytesize field to a uint16_t (with a RELEASE_ASSERT that we never overflow it) and moving the StackSlotKind in the hole this creates. Total savings: 16 bytes per spill slot and 40 bytes per locked (by B3) slot. * _javascript_Core.xcodeproj/project.pbxproj: * Sources.txt: * b3/B3LowerToAir.cpp: * b3/B3Procedure.cpp: (JSC::B3::Procedure::addStackSlot): (JSC::B3::Procedure::dump const): * b3/B3Procedure.h: * b3/B3ProcedureInlines.h: (JSC::B3::Procedure::stackSlots): (JSC::B3::Procedure::stackSlots const): * b3/B3SlotBaseValue.cpp: * b3/B3SlotBaseValue.h: * b3/B3StackSlot.cpp: Removed. * b3/B3StackSlot.h: Removed. * b3/B3Value.cpp: * b3/air/AirCode.cpp: (JSC::B3::Air::Code::addStackSlot): * b3/air/AirCode.h: * b3/air/AirStackSlot.cpp: (JSC::B3::Air::StackSlot::setOffsetFromFP): (JSC::B3::Air::StackSlot::deepDump const): (JSC::B3::Air::StackSlot::StackSlot): * b3/air/AirStackSlot.h: (JSC::B3::Air::StackSlot::ensureSize): * b3/testb3.h: * ftl/FTLCompile.cpp: * ftl/FTLState.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj trunk/Source/_javascript_Core/Sources.txt trunk/Source/_javascript_Core/b3/B3LowerToAir.cpp trunk/Source/_javascript_Core/b3/B3Procedure.cpp trunk/Source/_javascript_Core/b3/B3Procedure.h trunk/Source/_javascript_Core/b3/B3ProcedureInlines.h trunk/Source/_javascript_Core/b3/B3SlotBaseValue.cpp trunk/Source/_javascript_Core/b3/B3SlotBaseValue.h trunk/Source/_javascript_Core/b3/B3Value.cpp trunk/Source/_javascript_Core/b3/air/AirCode.cpp trunk/Source/_javascript_Core/b3/air/AirCode.h trunk/Source/_javascript_Core/b3/air/AirStackSlot.cpp trunk/Source/_javascript_Core/b3/air/AirStackSlot.h trunk/Source/_javascript_Core/b3/testb3.h trunk/Source/_javascript_Core/ftl/FTLCompile.cpp trunk/Source/_javascript_Core/ftl/FTLState.h Removed Paths trunk/Source/_javascript_Core/b3/B3StackSlot.cpp trunk/Source/_javascript_Core/b3/B3StackSlot.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (278380 => 278381) --- trunk/Source/_javascript_Core/ChangeLog 2021-06-02 23:10:10 UTC (rev 278380) +++ trunk/Source/_javascript_Core/ChangeLog 2021-06-02 23:28:30 UTC (rev 278381) @@ -1,3 +1,47 @@ +2021-06-02 Robin Morisset + +Merge B3::StackSlot and Air::StackSlot +https://bugs.webkit.org/show_bug.cgi?id=226362 + +Reviewed by Filip Pizlo. + +This is a very simple and safe (although small) memory saving, since every B3StackSlot eventually becomes an AirStackSlot with an exact copy of all the same information. +Simply dropping the B3StackSlot past that point is tricky, because one of them might be retained by FTLState (and modified by Air). +It is much simpler to just use Air::StackSlot throughout. It saves us: +- 16 bytes per B3StackSlot (for the structure itself) +- another 8 bytes per B3StackSlot (for the pointer in the SparseCollection) +- 8 bytes per AirStackSlot (for the pointer to the B3::StackSlot) +I also took the opportunity to save an extra 8 bytes per AirStackSlot, by shrinking the bytesize field to a uint16_t (with a RELEASE_ASSERT that we never overflow it) and moving the StackSlotKind in the hole this creates. +Total savings: 16 bytes per spill slot and 40 bytes per locked (by B3) slot. + +* _javascript_Core.xcodeproj/project.pbxproj: +* Sources.txt: +* b3/B3LowerToAir.cpp: +* b3/B3Procedure.cpp: +(JSC::B3::Procedure::addStackSlot): +(JSC::B3::Procedure::dump const): +* b3/B3Procedure.h: +* b3/B3ProcedureInlines.h: +(JSC::B3::Procedure::stackSlots): +(JSC::B3::Procedure::stackSlots const): +* b3/B3SlotBaseValue.cpp: +* b3/B3SlotBaseValue.h: +* b3/B3StackSlot.cpp: Removed. +* b3/B3StackSlot.h: Removed. +* b3/B3Value.cpp: +* b3/air/AirCode.cpp: +(JSC::B3::Air::Code::addStackSlot): +* b3/air/AirCode.h: +* b3/air/AirStackSlot.cpp: +
[webkit-changes] [278371] trunk/Source/JavaScriptCore
Title: [278371] trunk/Source/_javascript_Core Revision 278371 Author rmoris...@apple.com Date 2021-06-02 13:45:55 -0700 (Wed, 02 Jun 2021) Log Message We should drop B3 values while running Air https://bugs.webkit.org/show_bug.cgi?id=226187 Reviewed by Saam Barati. We must keep the following values: - WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument. - CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of itsorigin. I intend to fix these in later patches if possible. Finally we must preserve all B3 values in the following cases: - if we dump the disassembly or the Air graph: because otherwise we cannot print the origins - if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins. We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments. We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State. Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise). The performance impact of this is a progression on various RAMification subtests on Mac, but is more mitigated on iPhone7, with various regressions. I suspect these to be noise, and will monitor the performance bots post-landing to make sure of it. * b3/B3LowerToAir.cpp: (JSC::B3::lowerToAir): * b3/B3Procedure.cpp: (JSC::B3::Procedure::freeUnneededB3ValuesAfterLowering): * b3/B3Procedure.h: (JSC::B3::Procedure::releasePCToOriginMap): (JSC::B3::Procedure::setNeedsPCToOriginMap): (JSC::B3::Procedure::needsPCToOriginMap): * b3/B3SparseCollection.h: (JSC::B3::SparseCollection::clearAll): (JSC::B3::SparseCollection::filterAndTransfer): * b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * b3/air/AirCode.h: (JSC::B3::Air::Code::shouldPreserveB3Origins const): * b3/air/AirGenerate.cpp: (JSC::B3::Air::generateWithAlreadyAllocatedRegisters): * ftl/FTLCompile.cpp: (JSC::FTL::compile): * ftl/FTLState.cpp: (JSC::FTL::State::State): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/B3Generate.cpp trunk/Source/_javascript_Core/b3/B3PCToOriginMap.h trunk/Source/_javascript_Core/b3/B3Procedure.cpp trunk/Source/_javascript_Core/b3/B3Procedure.h trunk/Source/_javascript_Core/b3/B3SparseCollection.h trunk/Source/_javascript_Core/b3/air/AirCode.cpp trunk/Source/_javascript_Core/b3/air/AirCode.h trunk/Source/_javascript_Core/b3/air/AirGenerate.cpp trunk/Source/_javascript_Core/b3/testb3_6.cpp trunk/Source/_javascript_Core/ftl/FTLCompile.cpp trunk/Source/_javascript_Core/ftl/FTLState.cpp Diff Modified: trunk/Source/_javascript_Core/ChangeLog (278370 => 278371) --- trunk/Source/_javascript_Core/ChangeLog 2021-06-02 20:34:21 UTC (rev 278370) +++ trunk/Source/_javascript_Core/ChangeLog 2021-06-02 20:45:55 UTC (rev 278371) @@ -1,3 +1,49 @@ +2021-06-02 Robin Morisset + +We should drop B3 values while running Air +https://bugs.webkit.org/show_bug.cgi?id=226187 + +Reviewed by Saam Barati. + +We must keep the following values: +- WasmBoundsCheck, to know whether it is Pinned or Maximum, and if it is pinned find its argument. +- CCall/Patch/Check/CheckAdd/CheckSub/CheckMul and all of their children, because all of these are lowered to Air::Patchpoint, which needs to know the type of its arguments, and does so by looking at the children of itsorigin. +I intend to fix these in later patches if possible. + +Finally we must preserve all B3 values in the following cases: +- if we dump the disassembly or the Air graph: because otherwise we cannot print the origins +- if we are using the sampling profiler, because it relies on PCToCodeOriginMap which we cannot accurately fill without these origins. + +We must also keep m_tuples alive, as it is used by Patchpoints in Air to understand the types of their arguments. +We also don't touch StackSlots (in this patch), because one of them is captured by FTL::State. + +Also now PCToOriginMap has a Vector with no inline capacity, since it is either quite large (if needed) or empty (otherwise). + +The performance impact of this is a progression on various RAMification subtests on Mac, but is more mitigated on iPhone7, with various regressions. +I suspect these to be noise, and will monitor the performance bots post-landing to make sure of it. + +* b3/B3LowerToAir.cpp: +(JSC::B3::lowerToAir): +* b3/B3Procedure.cpp: +(JSC::B3::Procedure::freeUnneededB3ValuesAfterLowering): +* b3/B3Procedure.h: +(JSC::B3::Procedure::releasePCToOriginMap): +
[webkit-changes] [278224] trunk
Title: [278224] trunk
Revision 278224
Author rmoris...@apple.com
Date 2021-05-28 13:17:41 -0700 (Fri, 28 May 2021)
Log Message
Fix LikelyDenseUnsignedIntegerSet::clear()
https://bugs.webkit.org/show_bug.cgi?id=226388
JSTests:
rdar://78607433
Reviewed by Mark Lam.
* stress/stack-allocation-regression.js: Added.
(foo):
Source/WTF:
Reviewed by Mark Lam.
There are two problems with it:
1) It calls BitVector::clearAll(), which does not free any memory.
Instead, it should call BitVector::~BitVector(), then do a placement new of a fresh BitVector (to get it back to its inline condition)
2) More problematically, it changes m_size before calling isBitVector() which relies crucially on the value of m_size.
So it is going to believe that it is in BitVector mode even when it is actually in HashSet mode.
* wtf/LikelyDenseUnsignedIntegerSet.h:
(WTF::LikelyDenseUnsignedIntegerSet::clear):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/LikelyDenseUnsignedIntegerSet.h
Added Paths
trunk/JSTests/stress/stack-allocation-regression.js
Diff
Modified: trunk/JSTests/ChangeLog (278223 => 278224)
--- trunk/JSTests/ChangeLog 2021-05-28 20:13:35 UTC (rev 278223)
+++ trunk/JSTests/ChangeLog 2021-05-28 20:17:41 UTC (rev 278224)
@@ -1,3 +1,14 @@
+2021-05-28 Robin Morisset
+
+Fix LikelyDenseUnsignedIntegerSet::clear()
+https://bugs.webkit.org/show_bug.cgi?id=226388
+rdar://78607433
+
+Reviewed by Mark Lam.
+
+* stress/stack-allocation-regression.js: Added.
+(foo):
+
2021-05-28 Saam Barati
Don't sink arguments past the context of the inline call frame they were created in
Added: trunk/JSTests/stress/stack-allocation-regression.js (0 => 278224)
--- trunk/JSTests/stress/stack-allocation-regression.js (rev 0)
+++ trunk/JSTests/stress/stack-allocation-regression.js 2021-05-28 20:17:41 UTC (rev 278224)
@@ -0,0 +1,8 @@
+//@ requireOptions("--forceEagerCompilation=1")
+
+function foo() {
+for (let a0 in 'a')
+for (let a1 in 'a')
+for (let i=0; i<10; i++);
+}
+foo();
Modified: trunk/Source/WTF/ChangeLog (278223 => 278224)
--- trunk/Source/WTF/ChangeLog 2021-05-28 20:13:35 UTC (rev 278223)
+++ trunk/Source/WTF/ChangeLog 2021-05-28 20:17:41 UTC (rev 278224)
@@ -1,3 +1,19 @@
+2021-05-28 Robin Morisset
+
+Fix LikelyDenseUnsignedIntegerSet::clear()
+https://bugs.webkit.org/show_bug.cgi?id=226388
+
+Reviewed by Mark Lam.
+
+There are two problems with it:
+1) It calls BitVector::clearAll(), which does not free any memory.
+Instead, it should call BitVector::~BitVector(), then do a placement new of a fresh BitVector (to get it back to its inline condition)
+2) More problematically, it changes m_size before calling isBitVector() which relies crucially on the value of m_size.
+So it is going to believe that it is in BitVector mode even when it is actually in HashSet mode.
+
+* wtf/LikelyDenseUnsignedIntegerSet.h:
+(WTF::LikelyDenseUnsignedIntegerSet::clear):
+
2021-05-28 Sam Weinig
Add stub implementation of CA separated portal bits for GraphicsLayer
Modified: trunk/Source/WTF/wtf/LikelyDenseUnsignedIntegerSet.h (278223 => 278224)
--- trunk/Source/WTF/wtf/LikelyDenseUnsignedIntegerSet.h 2021-05-28 20:13:35 UTC (rev 278223)
+++ trunk/Source/WTF/wtf/LikelyDenseUnsignedIntegerSet.h 2021-05-28 20:17:41 UTC (rev 278224)
@@ -77,15 +77,14 @@
void clear()
{
+if (isBitVector())
+m_inline.bitVector.~BitVector();
+else
+m_inline.hashSet.~HashSet();
+new (NotNull, _inline.bitVector) BitVector;
m_size = 0;
m_min = 0;
m_max = 0;
-if (isBitVector())
-m_inline.bitVector.clearAll();
-else {
-m_inline.hashSet.~HashSet();
-new (NotNull, _inline.bitVector) BitVector;
-}
}
bool contains(IndexType value) const
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [277984] trunk/Source/JavaScriptCore
Title: [277984] trunk/Source/_javascript_Core
Revision 277984
Author rmoris...@apple.com
Date 2021-05-24 17:03:46 -0700 (Mon, 24 May 2021)
Log Message
When running with --reportTotalPhaseTimes=1, we should also log the max time in a phase
https://bugs.webkit.org/show_bug.cgi?id=226196
Reviewed by Saam Barati.
It is especially useful when looking at DFG phases, since the GC may have to wait for them to finish.
* tools/CompilerTimingScope.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/tools/CompilerTimingScope.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (277983 => 277984)
--- trunk/Source/_javascript_Core/ChangeLog 2021-05-24 23:47:25 UTC (rev 277983)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-05-25 00:03:46 UTC (rev 277984)
@@ -1,3 +1,14 @@
+2021-05-24 Robin Morisset
+
+When running with --reportTotalPhaseTimes=1, we should also log the max time in a phase
+https://bugs.webkit.org/show_bug.cgi?id=226196
+
+Reviewed by Saam Barati.
+
+It is especially useful when looking at DFG phases, since the GC may have to wait for them to finish.
+
+* tools/CompilerTimingScope.cpp:
+
2021-05-24 Saam Barati
Allow CTI stubs to be generated off the main thread
Modified: trunk/Source/_javascript_Core/tools/CompilerTimingScope.cpp (277983 => 277984)
--- trunk/Source/_javascript_Core/tools/CompilerTimingScope.cpp 2021-05-24 23:47:25 UTC (rev 277983)
+++ trunk/Source/_javascript_Core/tools/CompilerTimingScope.cpp 2021-05-25 00:03:46 UTC (rev 277984)
@@ -49,11 +49,12 @@
for (auto& tuple : totals) {
if (String(std::get<0>(tuple)) == String(compilerName) && String(std::get<1>(tuple)) == String(name)) {
std::get<2>(tuple) += duration;
+std::get<3>(tuple) = std::max(std::get<3>(tuple), duration);
return std::get<2>(tuple);
}
}
-totals.append({ compilerName, name, duration });
+totals.append({ compilerName, name, duration, duration });
return duration;
}
@@ -61,12 +62,12 @@
{
for (auto& tuple : totals) {
dataLogLn(
-"[", std::get<0>(tuple), "] ", std::get<1>(tuple), " total ms: ", std::get<2>(tuple).milliseconds());
+"[", std::get<0>(tuple), "] ", std::get<1>(tuple), " total ms: ", std::get<2>(tuple).milliseconds(), " max ms: ", std::get<3>(tuple).milliseconds());
}
}
private:
-Vector> totals;
+Vector> totals;
Lock lock;
};
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [277817] trunk/Tools
Title: [277817] trunk/Tools
Revision 277817
Author rmoris...@apple.com
Date 2021-05-20 12:34:32 -0700 (Thu, 20 May 2021)
Log Message
The test of SmallSet.cpp should pass the right HashTrait to the HashSet it uses as a reference
https://bugs.webkit.org/show_bug.cgi?id=226027
Reviewed by Mark Lam.
SmallSet allows all values except for the max value.
So we test it on small values, including 0.
HashSet by default forbids 0, so it made the test crash.
We can trivially fix it by passing UnsignedWithZeroKeyHashTraits, which allows everything which is not max() or max()-1
* TestWebKitAPI/Tests/WTF/SmallSet.cpp:
(TestWebKitAPI::testSmallSetOfUnsigned):
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WTF/SmallSet.cpp
Diff
Modified: trunk/Tools/ChangeLog (277816 => 277817)
--- trunk/Tools/ChangeLog 2021-05-20 19:25:09 UTC (rev 277816)
+++ trunk/Tools/ChangeLog 2021-05-20 19:34:32 UTC (rev 277817)
@@ -1,3 +1,19 @@
+2021-05-20 Robin Morisset
+
+The test of SmallSet.cpp should pass the right HashTrait to the HashSet it uses as a reference
+https://bugs.webkit.org/show_bug.cgi?id=226027
+
+Reviewed by Mark Lam.
+
+SmallSet allows all values except for the max value.
+So we test it on small values, including 0.
+
+HashSet by default forbids 0, so it made the test crash.
+We can trivially fix it by passing UnsignedWithZeroKeyHashTraits, which allows everything which is not max() or max()-1
+
+* TestWebKitAPI/Tests/WTF/SmallSet.cpp:
+(TestWebKitAPI::testSmallSetOfUnsigned):
+
2021-05-20 Sam Sneddon
Add tox file for webkitpy
Modified: trunk/Tools/TestWebKitAPI/Tests/WTF/SmallSet.cpp (277816 => 277817)
--- trunk/Tools/TestWebKitAPI/Tests/WTF/SmallSet.cpp 2021-05-20 19:25:09 UTC (rev 277816)
+++ trunk/Tools/TestWebKitAPI/Tests/WTF/SmallSet.cpp 2021-05-20 19:34:32 UTC (rev 277817)
@@ -27,6 +27,7 @@
#include "Test.h"
#include
+#include
#include
#include
@@ -66,7 +67,7 @@
}
unsigned count = 0;
-HashSet referenceSet;
+HashSet, WTF::UnsignedWithZeroKeyHashTraits> referenceSet;
for (unsigned i : set) {
referenceSet.add(i);
++count;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [277748] trunk
Title: [277748] trunk
Revision 277748
Author rmoris...@apple.com
Date 2021-05-19 13:49:25 -0700 (Wed, 19 May 2021)
Log Message
Fix typo in AirUseCounts
https://bugs.webkit.org/show_bug.cgi?id=225977
rdar://78210501
Reviewed by Mark Lam.
JSTests:
Add the testcase found by Tuomas.
* stress/register-allocator-stress.js: Added.
(foo):
Source/_javascript_Core:
I had just messed up a copy-and-paste, using "gp" instead of "fp" in code that deals with floating point values.
This did not show in my tests, probably because few functions have more floating point temporaries than non-floating-point.
* b3/air/AirUseCounts.h:
(JSC::B3::Air::UseCounts::UseCounts):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/air/AirUseCounts.h
Added Paths
trunk/JSTests/stress/register-allocator-stress.js
Diff
Modified: trunk/JSTests/ChangeLog (277747 => 277748)
--- trunk/JSTests/ChangeLog 2021-05-19 20:30:27 UTC (rev 277747)
+++ trunk/JSTests/ChangeLog 2021-05-19 20:49:25 UTC (rev 277748)
@@ -1,3 +1,16 @@
+2021-05-19 Robin Morisset
+
+Fix typo in AirUseCounts
+https://bugs.webkit.org/show_bug.cgi?id=225977
+rdar://78210501
+
+Reviewed by Mark Lam.
+
+Add the testcase found by Tuomas.
+
+* stress/register-allocator-stress.js: Added.
+(foo):
+
2021-05-18 Keith Miller
Temporarily revert r276592 as it breaks some native apps
Added: trunk/JSTests/stress/register-allocator-stress.js (0 => 277748)
--- trunk/JSTests/stress/register-allocator-stress.js (rev 0)
+++ trunk/JSTests/stress/register-allocator-stress.js 2021-05-19 20:49:25 UTC (rev 277748)
@@ -0,0 +1,169 @@
+//@ requireOptions("--seedOfVMRandomForFuzzer=2539143341", "--useWideningNumberPredictionFuzzerAgent=1", "--jitPolicyScale=0")
+
+function foo(o) {
+ let result = 0;
+ for (let i = 0; i < 52; ++i) {
+let value = i | 0;
+switch (value) {
+ case 0:
+result += o?.a;
+break;
+ case 1:
+result += o?.b;
+break;
+ case 2:
+result += o.c;
+break;
+ case 3:
+result += o.d;
+break;
+ case 4:
+result += o.e;
+break;
+ case 5:
+result += o.f;
+break;
+ case 6:
+result += o.g;
+break;
+ case 7:
+result += o.h;
+break;
+ case 8:
+result += o.i;
+break;
+ case 9:
+result += o.j;
+break;
+ case 10:
+result += o.k;
+break;
+ case 11:
+result += o.a;
+break;
+ case 12:
+result += o.b;
+break;
+ case 13:
+result += o.c;
+break;
+ case 14:
+result += o.d;
+break;
+ case 15:
+result += o.e;
+break;
+ case 16:
+result += o.f;
+break;
+ case 17:
+result += o.g;
+break;
+ case 18:
+result += o.h;
+break;
+ case 19:
+result += o.i;
+break;
+ case 20:
+result += o.j;
+break;
+ case 21:
+result += o.k;
+break;
+ case 22:
+result += o.a;
+break;
+ case 23:
+result += o.a;
+break;
+ case 24:
+result += o.b;
+break;
+ case 25:
+result += o.c;
+break;
+ case 26:
+result += o.d;
+break;
+ case 27:
+result += o.e;
+break;
+ case 28:
+result += o.f;
+break;
+ case 29:
+result += o.g;
+break;
+ case 30:
+result += o.h;
+break;
+ case 31:
+result += o.i;
+break;
+ case 32:
+result += o.j;
+break;
+ case 33:
+result += o.k;
+break;
+ case 34:
+result += o.l;
+break;
+ case 36:
+result += o.a;
+break;
+ case 37:
+result += o.b;
+break;
+ case 38:
+result += o.c;
+break;
+ case 39:
+result += o.d;
+break;
+ case 40:
+result += o.e;
+break;
+ case 41:
+result += o.f;
+break;
+ case 42:
+result += o.g;
+break;
+ case 43:
+result += o.h;
+break;
+ case 44:
+result += o.i;
+break;
+ case 45:
+result += o.j;
+break;
+ case 46:
+result += o.k;
+break;
+ case 47:
+result += o.a;
+break;
+ case 48:
+result += o.b;
+break;
+ case 49:
+result += o.c;
+break;
+ case 50:
+result += o.d;
+break;
+ case 51:
+result += o.e;
+break;
+}
+ }
+ return result;
+}
+
+let o = {a: 0, b: 0, c: 0, d: 0, e: 0, f: 0, g: 0, h: 0, i: 0, j: 0, k: 0, l: 0};
+for (let i = 0; i < 10; ++i) {
[webkit-changes] [274882] trunk
Title: [274882] trunk
Revision 274882
Author rmoris...@apple.com
Date 2021-03-23 11:04:34 -0700 (Tue, 23 Mar 2021)
Log Message
Object.freeze(this) at the global scope can lose a reference to a WatchpointSet
https://bugs.webkit.org/show_bug.cgi?id=223608
Reviewed by Yusuke Suzuki.
JSTests:
* stress/freeze-global-object.js: Added.
(foo):
Source/_javascript_Core:
When freezing the global object, we should make a proper copy of symbol table entries, to keep any outstanding reference to the WatchpointSet.
We cannot use pack(), because it does not support FatEntries.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::setReadOnly):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp
trunk/Source/_javascript_Core/runtime/JSSymbolTableObject.h
trunk/Source/_javascript_Core/runtime/SymbolTable.h
Added Paths
trunk/JSTests/stress/freeze-global-object.js
Diff
Modified: trunk/JSTests/ChangeLog (274881 => 274882)
--- trunk/JSTests/ChangeLog 2021-03-23 18:00:02 UTC (rev 274881)
+++ trunk/JSTests/ChangeLog 2021-03-23 18:04:34 UTC (rev 274882)
@@ -1,3 +1,13 @@
+2021-03-23 Robin Morisset
+
+Object.freeze(this) at the global scope can lose a reference to a WatchpointSet
+https://bugs.webkit.org/show_bug.cgi?id=223608
+
+Reviewed by Yusuke Suzuki.
+
+* stress/freeze-global-object.js: Added.
+(foo):
+
2021-03-22 Saam Barati
LiteralParser shouldn't make error messages of length ~2^31
Added: trunk/JSTests/stress/freeze-global-object.js (0 => 274882)
--- trunk/JSTests/stress/freeze-global-object.js (rev 0)
+++ trunk/JSTests/stress/freeze-global-object.js 2021-03-23 18:04:34 UTC (rev 274882)
@@ -0,0 +1,2 @@
+Object.freeze(this);
+function foo() {}
Modified: trunk/Source/_javascript_Core/ChangeLog (274881 => 274882)
--- trunk/Source/_javascript_Core/ChangeLog 2021-03-23 18:00:02 UTC (rev 274881)
+++ trunk/Source/_javascript_Core/ChangeLog 2021-03-23 18:04:34 UTC (rev 274882)
@@ -1,3 +1,20 @@
+2021-03-23 Robin Morisset
+
+Object.freeze(this) at the global scope can lose a reference to a WatchpointSet
+https://bugs.webkit.org/show_bug.cgi?id=223608
+
+Reviewed by Yusuke Suzuki.
+
+When freezing the global object, we should make a proper copy of symbol table entries, to keep any outstanding reference to the WatchpointSet.
+We cannot use pack(), because it does not support FatEntries.
+
+* runtime/JSGlobalObject.cpp:
+(JSC::JSGlobalObject::defineOwnProperty):
+* runtime/JSSymbolTableObject.h:
+(JSC::symbolTableGet):
+* runtime/SymbolTable.h:
+(JSC::SymbolTableEntry::setReadOnly):
+
2021-03-22 Yusuke Suzuki
[JSC] JSCustomGetterFunction/JSCustomSetterFunction should use Identifier for their field
Modified: trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp (274881 => 274882)
--- trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp 2021-03-23 18:00:02 UTC (rev 274881)
+++ trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp 2021-03-23 18:04:34 UTC (rev 274882)
@@ -1484,7 +1484,7 @@
auto scope = DECLARE_THROW_SCOPE(vm);
JSGlobalObject* thisObject = jsCast(object);
-SymbolTableEntry::Fast entry;
+SymbolTableEntry entry;
PropertyDescriptor currentDescriptor;
if (symbolTableGet(thisObject, propertyName, entry, currentDescriptor)) {
bool isExtensible = false; // ignored since current descriptor is present
@@ -1502,7 +1502,8 @@
scope.assertNoException();
}
if (descriptor.writablePresent() && !descriptor.writable() && !entry.isReadOnly()) {
-thisObject->symbolTable()->set(propertyName.uid(), SymbolTableEntry(entry.varOffset(), entry.getAttributes() | PropertyAttribute::ReadOnly));
+entry.setReadOnly();
+thisObject->symbolTable()->set(propertyName.uid(), entry);
thisObject->varReadOnlyWatchpoint()->fireAll(vm, "GlobalVar was redefined as ReadOnly");
}
return true;
Modified: trunk/Source/_javascript_Core/runtime/JSSymbolTableObject.h (274881 => 274882)
--- trunk/Source/_javascript_Core/runtime/JSSymbolTableObject.h 2021-03-23 18:00:02 UTC (rev 274881)
+++ trunk/Source/_javascript_Core/runtime/JSSymbolTableObject.h 2021-03-23 18:04:34 UTC (rev 274882)
@@ -99,7 +99,7 @@
template
inline bool symbolTableGet(
-SymbolTableObjectType* object, PropertyName propertyName, SymbolTableEntry::Fast& entry, PropertyDescriptor& descriptor)
+SymbolTableObjectType* object, PropertyName propertyName, SymbolTableEntry& entry, PropertyDescriptor& descriptor)
{
SymbolTable& symbolTable = *object->symbolTable();
ConcurrentJSLocker locker(symbolTable.m_lock);
Modified:
[webkit-changes] [270766] trunk/Source/JavaScriptCore
Title: [270766] trunk/Source/_javascript_Core
Revision 270766
Author rmoris...@apple.com
Date 2020-12-14 03:46:06 -0800 (Mon, 14 Dec 2020)
Log Message
Minor cleanup of BigInts
https://bugs.webkit.org/show_bug.cgi?id=219253
Reviewed by Yusuke Suzuki.
* runtime/JSBigInt.cpp:
(JSC::rightShiftByAbsolute):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSBigInt.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (270765 => 270766)
--- trunk/Source/_javascript_Core/ChangeLog 2020-12-14 10:35:05 UTC (rev 270765)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-12-14 11:46:06 UTC (rev 270766)
@@ -1,3 +1,13 @@
+2020-12-14 Robin Morisset
+
+Minor cleanup of BigInts
+https://bugs.webkit.org/show_bug.cgi?id=219253
+
+Reviewed by Yusuke Suzuki.
+
+* runtime/JSBigInt.cpp:
+(JSC::rightShiftByAbsolute):
+
2020-12-13 Yusuke Suzuki
[JSC] Introduce vmEntryCustomAccessor and vmEntryHostFunction for JITCage
Modified: trunk/Source/_javascript_Core/runtime/JSBigInt.cpp (270765 => 270766)
--- trunk/Source/_javascript_Core/runtime/JSBigInt.cpp 2020-12-14 10:35:05 UTC (rev 270765)
+++ trunk/Source/_javascript_Core/runtime/JSBigInt.cpp 2020-12-14 11:46:06 UTC (rev 270766)
@@ -2048,6 +2048,7 @@
RETURN_IF_EXCEPTION(scope, nullptr);
if (!bitsShift) {
+result->setDigit(resultLength - 1, 0);
for (unsigned i = digitalShift; i < length; i++)
result->setDigit(i - digitalShift, x.digit(i));
} else {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [269107] trunk
Title: [269107] trunk
Revision 269107
Author rmoris...@apple.com
Date 2020-10-28 10:32:26 -0700 (Wed, 28 Oct 2020)
Log Message
DFGIntegerRangeOptimization is wrong for Upsilon (as 'shadow' nodes are not in SSA form)
https://bugs.webkit.org/show_bug.cgi?id=218073
Reviewed by Saam Barati.
JSTests:
The only testcase I managed to get for this bug loops forever when not crashing.
So I use a 1s timeout through --watchdog=1000.
* stress/bounds-checking-in-cold-loop.js: Added.
(true.vm.ftlTrue):
Source/_javascript_Core:
In DFGIntegerRangeOptimization, when visiting an Upsilon node, we call setEquivalence, that calls setRelationship.
But despite its name, this function does not overwrite a pre-existing relationship, it simply replaces it by an over-approximation of the intersection of the old and new relationship (see the filter method).
Since the old relationship is always (by definition) an over-approximation of this intersection, it will often do nothing at all if it cannot find a closer approximation.
This is a problem specifically for Upsilon nodes, because several of them can store to the same "shadow node" corresponding to a given Phi, so they are the only case where there can already be a completely different relationship for the same nodes (coming from a different Upsilon).
The fix is very simple thanks to a suggestion by Phil: we just remove all relationships referring to the shadow node just before executing an Upsilon.
This is correct since the upsilon effectively kills that shadow node, before making it live again with a different value, and we already aggressively prune the relationshipMaps by liveness.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGIntegerRangeOptimizationPhase.cpp
Added Paths
trunk/JSTests/stress/bounds-checking-in-cold-loop.js
Diff
Modified: trunk/JSTests/ChangeLog (269106 => 269107)
--- trunk/JSTests/ChangeLog 2020-10-28 16:17:10 UTC (rev 269106)
+++ trunk/JSTests/ChangeLog 2020-10-28 17:32:26 UTC (rev 269107)
@@ -1,3 +1,16 @@
+2020-10-28 Robin Morisset
+
+DFGIntegerRangeOptimization is wrong for Upsilon (as 'shadow' nodes are not in SSA form)
+https://bugs.webkit.org/show_bug.cgi?id=218073
+
+Reviewed by Saam Barati.
+
+The only testcase I managed to get for this bug loops forever when not crashing.
+So I use a 1s timeout through --watchdog=1000.
+
+* stress/bounds-checking-in-cold-loop.js: Added.
+(true.vm.ftlTrue):
+
2020-10-24 Yusuke Suzuki
[ECMA-402] Implement Intl.ListFormat
Added: trunk/JSTests/stress/bounds-checking-in-cold-loop.js (0 => 269107)
--- trunk/JSTests/stress/bounds-checking-in-cold-loop.js (rev 0)
+++ trunk/JSTests/stress/bounds-checking-in-cold-loop.js 2020-10-28 17:32:26 UTC (rev 269107)
@@ -0,0 +1,12 @@
+//@ runFTLEager("--watchdog=1000", "--watchdog-exception-ok")
+let a = [];
+a[0] = undefined;
+
+while (true) {
+ let i = 0;
+ a[0];
+ while ($vm.ftlTrue()) {
+a[i++] = undefined;
+ }
+}
+
Modified: trunk/Source/_javascript_Core/ChangeLog (269106 => 269107)
--- trunk/Source/_javascript_Core/ChangeLog 2020-10-28 16:17:10 UTC (rev 269106)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-10-28 17:32:26 UTC (rev 269107)
@@ -1,3 +1,20 @@
+2020-10-28 Robin Morisset
+
+DFGIntegerRangeOptimization is wrong for Upsilon (as 'shadow' nodes are not in SSA form)
+https://bugs.webkit.org/show_bug.cgi?id=218073
+
+Reviewed by Saam Barati.
+
+In DFGIntegerRangeOptimization, when visiting an Upsilon node, we call setEquivalence, that calls setRelationship.
+But despite its name, this function does not overwrite a pre-existing relationship, it simply replaces it by an over-approximation of the intersection of the old and new relationship (see the filter method).
+Since the old relationship is always (by definition) an over-approximation of this intersection, it will often do nothing at all if it cannot find a closer approximation.
+This is a problem specifically for Upsilon nodes, because several of them can store to the same "shadow node" corresponding to a given Phi, so they are the only case where there can already be a completely different relationship for the same nodes (coming from a different Upsilon).
+
+The fix is very simple thanks to a suggestion by Phil: we just remove all relationships referring to the shadow node just before executing an Upsilon.
+This is correct since the upsilon effectively kills that shadow node, before making it live again with a different value, and we already aggressively prune the relationshipMaps by liveness.
+
+* dfg/DFGIntegerRangeOptimizationPhase.cpp:
+
2020-10-27 Michael Catanzaro
-Wparentheses warning in OptionsList.h
Modified:
[webkit-changes] [268871] trunk/Source/JavaScriptCore
Title: [268871] trunk/Source/_javascript_Core
Revision 268871
Author rmoris...@apple.com
Date 2020-10-22 10:45:53 -0700 (Thu, 22 Oct 2020)
Log Message
Use operand names when dumping Bytecode
https://bugs.webkit.org/show_bug.cgi?id=218084
Reviewed by Saam Barati.
For example this would output the following:
[ 258] put_to_scope scope:loc7, var:3, value:loc8, getPutInfo:1048576, symbolTableOrScopeDepth:0, offset:0
instead of
[ 258] put_to_scope loc7, 3, loc8, 1048576, 0, 0
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumperBase::dumpOperand):
* generator/Opcode.rb:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecode/BytecodeDumper.h
trunk/Source/_javascript_Core/generator/Opcode.rb
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (268870 => 268871)
--- trunk/Source/_javascript_Core/ChangeLog 2020-10-22 17:31:05 UTC (rev 268870)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-10-22 17:45:53 UTC (rev 268871)
@@ -1,3 +1,19 @@
+2020-10-22 Robin Morisset
+
+Use operand names when dumping Bytecode
+https://bugs.webkit.org/show_bug.cgi?id=218084
+
+Reviewed by Saam Barati.
+
+For example this would output the following:
+ [ 258] put_to_scope scope:loc7, var:3, value:loc8, getPutInfo:1048576, symbolTableOrScopeDepth:0, offset:0
+instead of
+ [ 258] put_to_scope loc7, 3, loc8, 1048576, 0, 0
+
+* bytecode/BytecodeDumper.h:
+(JSC::BytecodeDumperBase::dumpOperand):
+* generator/Opcode.rb:
+
2020-10-21 Caitlin Potter
[JSC] support op_get_private_name in DFG and FTL
Modified: trunk/Source/_javascript_Core/bytecode/BytecodeDumper.h (268870 => 268871)
--- trunk/Source/_javascript_Core/bytecode/BytecodeDumper.h 2020-10-22 17:31:05 UTC (rev 268870)
+++ trunk/Source/_javascript_Core/bytecode/BytecodeDumper.h 2020-10-22 17:45:53 UTC (rev 268871)
@@ -47,10 +47,12 @@
void printLocationAndOp(InstructionStream::Offset location, const char* op);
template
-void dumpOperand(T operand, bool isFirst = false)
+void dumpOperand(const char* operandName, T operand, bool isFirst = false)
{
if (!isFirst)
m_out.print(", ");
+m_out.print(operandName);
+m_out.print(":");
dumpValue(operand);
}
Modified: trunk/Source/_javascript_Core/generator/Opcode.rb (268870 => 268871)
--- trunk/Source/_javascript_Core/generator/Opcode.rb 2020-10-22 17:31:05 UTC (rev 268870)
+++ trunk/Source/_javascript_Core/generator/Opcode.rb 2020-10-22 17:45:53 UTC (rev 268871)
@@ -269,7 +269,7 @@
dumper->printLocationAndOp(__location, &"**#{@name}"[2 - __sizeShiftAmount]);
#{print_args { |arg|
<<-EOF.chomp
-dumper->dumpOperand(#{arg.field_name}, #{arg.index == 0});
+dumper->dumpOperand("#{arg.name}", #{arg.field_name}, #{arg.index == 0});
EOF
}}
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [265378] trunk/Source/WTF
Title: [265378] trunk/Source/WTF
Revision 265378
Author rmoris...@apple.com
Date 2020-08-07 09:39:30 -0700 (Fri, 07 Aug 2020)
Log Message
Fix inequality in newly added assertion
https://bugs.webkit.org/show_bug.cgi?id=215272
Reviewed by Alexey Proskuryakov.
No new tests, as it was caught by our testing infrastructure (not sure why it only got caught after landing).
* wtf/IndexSparseSet.h:
(WTF::OverflowHandler>::validate):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/IndexSparseSet.h
Diff
Modified: trunk/Source/WTF/ChangeLog (265377 => 265378)
--- trunk/Source/WTF/ChangeLog 2020-08-07 16:36:39 UTC (rev 265377)
+++ trunk/Source/WTF/ChangeLog 2020-08-07 16:39:30 UTC (rev 265378)
@@ -1,5 +1,17 @@
2020-08-07 Robin Morisset
+Fix inequality in newly added assertion
+https://bugs.webkit.org/show_bug.cgi?id=215272
+
+Reviewed by Alexey Proskuryakov.
+
+No new tests, as it was caught by our testing infrastructure (not sure why it only got caught after landing).
+
+* wtf/IndexSparseSet.h:
+(WTF::OverflowHandler>::validate):
+
+2020-08-07 Robin Morisset
+
IndexSparseSet::sort() should update m_map
https://bugs.webkit.org/show_bug.cgi?id=215100
Modified: trunk/Source/WTF/wtf/IndexSparseSet.h (265377 => 265378)
--- trunk/Source/WTF/wtf/IndexSparseSet.h 2020-08-07 16:36:39 UTC (rev 265377)
+++ trunk/Source/WTF/wtf/IndexSparseSet.h 2020-08-07 16:39:30 UTC (rev 265378)
@@ -232,7 +232,7 @@
template
void IndexSparseSet::validate()
{
-RELEASE_ASSERT(m_values.size() < m_map.size());
+RELEASE_ASSERT(m_values.size() <= m_map.size());
for (const EntryType& entry : *this)
RELEASE_ASSERT(contains(EntryTypeTraits::key(entry)));
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [265371] trunk
Title: [265371] trunk
Revision 265371
Author rmoris...@apple.com
Date 2020-08-07 07:13:24 -0700 (Fri, 07 Aug 2020)
Log Message
IndexSparseSet::sort() should update m_map
https://bugs.webkit.org/show_bug.cgi?id=215100
Reviewed by Yusuke Suzuki and Mark Lam.
Source/WTF:
IndexSparseSet is made of two fields: m_values and m_map, and the two must be kept in sync.
But its sort routine currently only sorts m_values.
This might be related to a random crash that seems to occasionally occur in the vicinity of this code in the wild (rdar://problem/64594569)
I added a validation routine, that I run in the tests that I added to TestWTF.
I verified, and without the fix, the validation routine fails after the sorting.
I also fixed remove() which was wrong on non-trivial types (thanks to Mark for catching this other bug).
* wtf/IndexSparseSet.h:
(WTF::OverflowHandler>::remove):
(WTF::OverflowHandler>::sort):
(WTF::OverflowHandler>::validate):
Tools:
TestWTF was not testing IndexSparseSet at all. It now does.
* TestWebKitAPI/CMakeLists.txt:
* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
* TestWebKitAPI/Tests/WTF/IndexSparseSet.cpp: Added.
(TestWebKitAPI::TEST):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/IndexSparseSet.h
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/CMakeLists.txt
trunk/Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj
Added Paths
trunk/Tools/TestWebKitAPI/Tests/WTF/IndexSparseSet.cpp
Diff
Modified: trunk/Source/WTF/ChangeLog (265370 => 265371)
--- trunk/Source/WTF/ChangeLog 2020-08-07 14:05:04 UTC (rev 265370)
+++ trunk/Source/WTF/ChangeLog 2020-08-07 14:13:24 UTC (rev 265371)
@@ -1,3 +1,24 @@
+2020-08-07 Robin Morisset
+
+IndexSparseSet::sort() should update m_map
+https://bugs.webkit.org/show_bug.cgi?id=215100
+
+Reviewed by Yusuke Suzuki and Mark Lam.
+
+IndexSparseSet is made of two fields: m_values and m_map, and the two must be kept in sync.
+But its sort routine currently only sorts m_values.
+This might be related to a random crash that seems to occasionally occur in the vicinity of this code in the wild (rdar://problem/64594569)
+
+I added a validation routine, that I run in the tests that I added to TestWTF.
+I verified, and without the fix, the validation routine fails after the sorting.
+
+I also fixed remove() which was wrong on non-trivial types (thanks to Mark for catching this other bug).
+
+* wtf/IndexSparseSet.h:
+(WTF::OverflowHandler>::remove):
+(WTF::OverflowHandler>::sort):
+(WTF::OverflowHandler>::validate):
+
2020-08-07 Youenn Fablet
Introduce a Vector::isolatedCopy() &&
Modified: trunk/Source/WTF/wtf/IndexSparseSet.h (265370 => 265371)
--- trunk/Source/WTF/wtf/IndexSparseSet.h 2020-08-07 14:05:04 UTC (rev 265370)
+++ trunk/Source/WTF/wtf/IndexSparseSet.h 2020-08-07 14:13:24 UTC (rev 265371)
@@ -99,6 +99,8 @@
const_iterator end() const;
void sort();
+
+void validate();
const ValueList& values() const { return m_values; }
@@ -148,7 +150,7 @@
if (position >= m_values.size())
return false;
-if (m_values[position] == value) {
+if (EntryTypeTraits::key(m_values[position]) == value) {
EntryType lastValue = m_values.last();
m_values[position] = WTFMove(lastValue);
m_map[EntryTypeTraits::key(lastValue)] = position;
@@ -215,9 +217,27 @@
[&] (const EntryType& a, const EntryType& b) {
return EntryTypeTraits::key(a) < EntryTypeTraits::key(b);
});
+
+// Bring m_map back in sync with m_values
+for (unsigned index = 0; index < m_values.size(); ++index) {
+unsigned key = EntryTypeTraits::key(m_values[index]);
+m_map[key] = index;
+}
+
+#if ASSERT_ENABLED
+validate();
+#endif
}
template
+void IndexSparseSet::validate()
+{
+RELEASE_ASSERT(m_values.size() < m_map.size());
+for (const EntryType& entry : *this)
+RELEASE_ASSERT(contains(EntryTypeTraits::key(entry)));
+}
+
+template
auto IndexSparseSet::begin() const -> const_iterator
{
return m_values.begin();
Modified: trunk/Tools/ChangeLog (265370 => 265371)
--- trunk/Tools/ChangeLog 2020-08-07 14:05:04 UTC (rev 265370)
+++ trunk/Tools/ChangeLog 2020-08-07 14:13:24 UTC (rev 265371)
@@ -1,3 +1,17 @@
+2020-08-07 Robin Morisset
+
+IndexSparseSet::sort() should update m_map
+https://bugs.webkit.org/show_bug.cgi?id=215100
+
+Reviewed by Yusuke Suzuki and Mark Lam.
+
+TestWTF was not testing IndexSparseSet at all. It now does.
+
+* TestWebKitAPI/CMakeLists.txt:
+* TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
+* TestWebKitAPI/Tests/WTF/IndexSparseSet.cpp: Added.
+(TestWebKitAPI::TEST):
+
2020-08-07 Aakash Jain
EWS emails about build failure should include last few relevant error logs
Modified:
[webkit-changes] [263068] trunk/Source/JavaScriptCore
Title: [263068] trunk/Source/_javascript_Core
Revision 263068
Author rmoris...@apple.com
Date 2020-06-15 17:10:31 -0700 (Mon, 15 Jun 2020)
Log Message
testB3::testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead() has a validation failure in debug mode
https://bugs.webkit.org/show_bug.cgi?id=196103
Reviewed by Keith Miller.
The problem was trivial: patchpoints were referring to constants that were defined after them.
Just exchanging the order of the definition was enough to make this test pass.
* b3/testb3_1.cpp:
(shouldRun):
* b3/testb3_7.cpp:
(testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/testb3_1.cpp
trunk/Source/_javascript_Core/b3/testb3_7.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (263067 => 263068)
--- trunk/Source/_javascript_Core/ChangeLog 2020-06-15 23:00:04 UTC (rev 263067)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-06-16 00:10:31 UTC (rev 263068)
@@ -1,3 +1,19 @@
+2020-06-15 Robin Morisset
+
+testB3::testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead() has a validation failure in debug mode
+https://bugs.webkit.org/show_bug.cgi?id=196103
+
+
+Reviewed by Keith Miller.
+
+The problem was trivial: patchpoints were referring to constants that were defined after them.
+Just exchanging the order of the definition was enough to make this test pass.
+
+* b3/testb3_1.cpp:
+(shouldRun):
+* b3/testb3_7.cpp:
+(testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead):
+
2020-06-15 Mark Lam
Do not install the VMTraps signal handler if Options::useJIT=false.
Modified: trunk/Source/_javascript_Core/b3/testb3_1.cpp (263067 => 263068)
--- trunk/Source/_javascript_Core/b3/testb3_1.cpp 2020-06-15 23:00:04 UTC (rev 263067)
+++ trunk/Source/_javascript_Core/b3/testb3_1.cpp 2020-06-16 00:10:31 UTC (rev 263068)
@@ -35,7 +35,6 @@
// FIXME: These tests fail .
if (!filter && isARM64()) {
for (auto& failingTest : {
-"testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead",
"testNegFloatWithUselessDoubleConversion",
"testPinRegisters",
}) {
@@ -45,16 +44,6 @@
}
}
}
-if (!filter && isX86()) {
-for (auto& failingTest : {
-"testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead",
-}) {
-if (WTF::findIgnoringASCIICaseWithoutLength(testName, failingTest) != WTF::notFound) {
-dataLogLn("*** Warning: Skipping known-bad test: ", testName);
-return false;
-}
-}
-}
return !filter || WTF::findIgnoringASCIICaseWithoutLength(testName, filter) != WTF::notFound;
}
Modified: trunk/Source/_javascript_Core/b3/testb3_7.cpp (263067 => 263068)
--- trunk/Source/_javascript_Core/b3/testb3_7.cpp 2020-06-15 23:00:04 UTC (rev 263067)
+++ trunk/Source/_javascript_Core/b3/testb3_7.cpp 2020-06-16 00:10:31 UTC (rev 263068)
@@ -1468,8 +1468,8 @@
{
// Make every reg 42 (just needs to be a value other than 10).
+Value* const42 = root->appendNew(proc, Origin(), 42);
PatchpointValue* patchpoint = root->appendNew(proc, Void, Origin());
-Value* const42 = root->appendNew(proc, Origin(), 42);
for (Reg reg : allRegs)
patchpoint->append(const42, ValueRep::reg(reg));
patchpoint->setGenerator([&] (CCallHelpers&, const StackmapGenerationParams&) { });
@@ -1476,8 +1476,8 @@
}
{
+Value* const10 = root->appendNew(proc, Origin(), 10);
PatchpointValue* patchpoint = root->appendNew(proc, Void, Origin());
-Value* const10 = root->appendNew(proc, Origin(), 10);
for (Reg reg : allRegs)
patchpoint->append(const10, ValueRep::lateReg(reg));
patchpoint->setGenerator([&] (CCallHelpers& jit, const StackmapGenerationParams&) {
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [262995] trunk
Title: [262995] trunk
Revision 262995
Author rmoris...@apple.com
Date 2020-06-12 20:09:21 -0700 (Fri, 12 Jun 2020)
Log Message
The ||= operator (and similar ones) should produce valid bytecode even if the right side is a static error
https://bugs.webkit.org/show_bug.cgi?id=213154
Reviewed by Devin Rousso.
JSTests:
* stress/bytecode-for-rmw-with-invalid-right-side.js: Added.
(catch):
Source/_javascript_Core:
There were two minor issues here that interacted:
- emitThrowReferenceError did not take an optional `dst` argument like everything else, and instead always returned a new temporary.
As a result, the various functions that sometimes did "return emitThrowReferenceError(..);" could return a different RegisterID than the one
provided to them through `dst`, breaking the invariant stated at the top of the file.
- ShortCircuitReadModifyResolveNode::emitBytecode used the result of such a function, unnecessarily, and (correctly) relied on the invariant being upheld.
The combination of these led to the bytecode trying to do a move of a temporary that was only defined in one of the predecessors of the basic block it was on,
which was caught by validateBytecode.
I fixed both issues, and verified that either fix is enough to stop the bug.
I fixed the first because other code may depend on that invariant in more subtle ways.
I fixed the second because it was just unnecessary complexity and made the code misleading.
I also reworded the comment at the top of NodesCodegen.cpp based on Keith's explanation and Mark's advice to make it less cryptic.
* bytecompiler/NodesCodegen.cpp:
(JSC::ThrowableExpressionData::emitThrowReferenceError):
(JSC::PostfixNode::emitBytecode):
(JSC::DeleteBracketNode::emitBytecode):
(JSC::DeleteDotNode::emitBytecode):
(JSC::PrefixNode::emitBytecode):
(JSC::ShortCircuitReadModifyResolveNode::emitBytecode):
(JSC::AssignErrorNode::emitBytecode):
* parser/Nodes.h:
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp
trunk/Source/_javascript_Core/parser/Nodes.h
Added Paths
trunk/JSTests/stress/bytecode-for-rmw-with-invalid-right-side.js
Diff
Modified: trunk/JSTests/ChangeLog (262994 => 262995)
--- trunk/JSTests/ChangeLog 2020-06-13 02:55:27 UTC (rev 262994)
+++ trunk/JSTests/ChangeLog 2020-06-13 03:09:21 UTC (rev 262995)
@@ -1,3 +1,13 @@
+2020-06-12 Robin Morisset
+
+The ||= operator (and similar ones) should produce valid bytecode even if the right side is a static error
+https://bugs.webkit.org/show_bug.cgi?id=213154
+
+Reviewed by Devin Rousso.
+
+* stress/bytecode-for-rmw-with-invalid-right-side.js: Added.
+(catch):
+
2020-06-12 Yusuke Suzuki
[JSC] el(Greek) characters' upper-case conversion is locale-sensitive
Added: trunk/JSTests/stress/bytecode-for-rmw-with-invalid-right-side.js (0 => 262995)
--- trunk/JSTests/stress/bytecode-for-rmw-with-invalid-right-side.js (rev 0)
+++ trunk/JSTests/stress/bytecode-for-rmw-with-invalid-right-side.js 2020-06-13 03:09:21 UTC (rev 262995)
@@ -0,0 +1,9 @@
+//@ runDefault("--validateBytecode=1")
+try {
+x||=y()=0
+x||=(y()++)
+x||=(++y())
+x||=(y()+=0)
+x||=(y()||=0)
+} catch(e) {
+}
Modified: trunk/Source/_javascript_Core/ChangeLog (262994 => 262995)
--- trunk/Source/_javascript_Core/ChangeLog 2020-06-13 02:55:27 UTC (rev 262994)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-06-13 03:09:21 UTC (rev 262995)
@@ -1,3 +1,34 @@
+2020-06-12 Robin Morisset
+
+The ||= operator (and similar ones) should produce valid bytecode even if the right side is a static error
+https://bugs.webkit.org/show_bug.cgi?id=213154
+
+Reviewed by Devin Rousso.
+
+There were two minor issues here that interacted:
+- emitThrowReferenceError did not take an optional `dst` argument like everything else, and instead always returned a new temporary.
+ As a result, the various functions that sometimes did "return emitThrowReferenceError(..);" could return a different RegisterID than the one
+ provided to them through `dst`, breaking the invariant stated at the top of the file.
+- ShortCircuitReadModifyResolveNode::emitBytecode used the result of such a function, unnecessarily, and (correctly) relied on the invariant being upheld.
+The combination of these led to the bytecode trying to do a move of a temporary that was only defined in one of the predecessors of the basic block it was on,
+which was caught by validateBytecode.
+
+I fixed both issues, and verified that either fix is enough to stop the bug.
+I fixed the first because other code may depend on that invariant in more subtle ways.
+I fixed the second because it was just unnecessary complexity and made the code misleading.
+
+I also reworded the comment at the top of NodesCodegen.cpp based on
[webkit-changes] [262040] trunk
Title: [262040] trunk
Revision 262040
Author rmoris...@apple.com
Date 2020-05-21 19:17:54 -0700 (Thu, 21 May 2020)
Log Message
Various compile-time boolean flags could/should be marked constexpr
https://bugs.webkit.org/show_bug.cgi?id=212244
Reviewed by Mark Lam.
Source/_javascript_Core:
This trivial patch saves roughly 16kB from the _javascript_Core binary in release mode.
* b3/B3OptimizeAssociativeExpressionTrees.cpp:
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* b3/air/AirSimplifyCFG.cpp:
(JSC::B3::Air::simplifyCFG):
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
* dfg/DFGPredictionPropagationPhase.cpp:
* heap/GCIncomingRefCountedInlines.h:
(JSC::GCIncomingRefCounted::filterIncomingReferences):
* heap/Heap.cpp:
(JSC::Heap::updateAllocationLimits):
* wasm/WasmEntryPlan.cpp:
Source/WTF:
* wtf/ParkingLot.cpp:
Tools:
* TestWebKitAPI/Tests/WTF/Condition.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3OptimizeAssociativeExpressionTrees.cpp
trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp
trunk/Source/_javascript_Core/b3/air/AirSimplifyCFG.cpp
trunk/Source/_javascript_Core/b3/air/AirTmpWidth.cpp
trunk/Source/_javascript_Core/dfg/DFGPredictionPropagationPhase.cpp
trunk/Source/_javascript_Core/heap/GCIncomingRefCountedInlines.h
trunk/Source/_javascript_Core/heap/Heap.cpp
trunk/Source/_javascript_Core/wasm/WasmEntryPlan.cpp
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/ParkingLot.cpp
trunk/Tools/ChangeLog
trunk/Tools/TestWebKitAPI/Tests/WTF/Condition.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (262039 => 262040)
--- trunk/Source/_javascript_Core/ChangeLog 2020-05-22 00:39:30 UTC (rev 262039)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-05-22 02:17:54 UTC (rev 262040)
@@ -1,5 +1,27 @@
2020-05-21 Robin Morisset
+Various compile-time boolean flags could/should be marked constexpr
+https://bugs.webkit.org/show_bug.cgi?id=212244
+
+Reviewed by Mark Lam.
+
+This trivial patch saves roughly 16kB from the _javascript_Core binary in release mode.
+
+* b3/B3OptimizeAssociativeExpressionTrees.cpp:
+* b3/air/AirAllocateRegistersByGraphColoring.cpp:
+* b3/air/AirSimplifyCFG.cpp:
+(JSC::B3::Air::simplifyCFG):
+* b3/air/AirTmpWidth.cpp:
+(JSC::B3::Air::TmpWidth::recompute):
+* dfg/DFGPredictionPropagationPhase.cpp:
+* heap/GCIncomingRefCountedInlines.h:
+(JSC::GCIncomingRefCounted::filterIncomingReferences):
+* heap/Heap.cpp:
+(JSC::Heap::updateAllocationLimits):
+* wasm/WasmEntryPlan.cpp:
+
+2020-05-21 Robin Morisset
+
Remove AssemblerBufferWithConstantPool.h (as it has been dead for years)
https://bugs.webkit.org/show_bug.cgi?id=212241
Modified: trunk/Source/_javascript_Core/b3/B3OptimizeAssociativeExpressionTrees.cpp (262039 => 262040)
--- trunk/Source/_javascript_Core/b3/B3OptimizeAssociativeExpressionTrees.cpp 2020-05-22 00:39:30 UTC (rev 262039)
+++ trunk/Source/_javascript_Core/b3/B3OptimizeAssociativeExpressionTrees.cpp 2020-05-22 02:17:54 UTC (rev 262040)
@@ -57,7 +57,7 @@
bool optimizeRootedTree(Value* root, InsertionSet&, size_t indexInBlock, const Vector& useCounts);
Procedure& m_proc;
-bool verbose { false };
+static constexpr bool verbose { false };
};
int64_t OptimizeAssociativeExpressionTrees::neutralElement(Opcode op)
Modified: trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp (262039 => 262040)
--- trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2020-05-22 00:39:30 UTC (rev 262039)
+++ trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2020-05-22 02:17:54 UTC (rev 262040)
@@ -43,9 +43,9 @@
namespace {
-bool debug = false;
-bool traceDebug = false;
-bool reportStats = false;
+static constexpr bool debug = false;
+static constexpr bool traceDebug = false;
+static constexpr bool reportStats = false;
// The AbstractColoringAllocator defines all the code that is independant
// from the bank or register and can be shared when allocating registers.
Modified: trunk/Source/_javascript_Core/b3/air/AirSimplifyCFG.cpp (262039 => 262040)
--- trunk/Source/_javascript_Core/b3/air/AirSimplifyCFG.cpp 2020-05-22 00:39:30 UTC (rev 262039)
+++ trunk/Source/_javascript_Core/b3/air/AirSimplifyCFG.cpp 2020-05-22 02:17:54 UTC (rev 262040)
@@ -35,7 +35,7 @@
bool simplifyCFG(Code& code)
{
-const bool verbose = false;
+constexpr bool verbose = false;
PhaseScope phaseScope(code, "simplifyCFG");
Modified: trunk/Source/_javascript_Core/b3/air/AirTmpWidth.cpp (262039 => 262040)
--- trunk/Source/_javascript_Core/b3/air/AirTmpWidth.cpp 2020-05-22 00:39:30 UTC (rev 262039)
+++ trunk/Source/_javascript_Core/b3/air/AirTmpWidth.cpp 2020-05-22 02:17:54 UTC (rev 262040)
@@ -52,7 +52,7 @@
// Set
[webkit-changes] [262039] trunk/Source/JavaScriptCore
Title: [262039] trunk/Source/_javascript_Core
Revision 262039
Author rmoris...@apple.com
Date 2020-05-21 17:39:30 -0700 (Thu, 21 May 2020)
Log Message
Remove AssemblerBufferWithConstantPool.h (as it has been dead for years)
https://bugs.webkit.org/show_bug.cgi?id=212241
Reviewed by Yusuke Suzuki.
* CMakeLists.txt:
* _javascript_Core.xcodeproj/project.pbxproj:
* assembler/AssemblerBufferWithConstantPool.h: Removed.
Modified Paths
trunk/Source/_javascript_Core/CMakeLists.txt
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj
Removed Paths
trunk/Source/_javascript_Core/assembler/AssemblerBufferWithConstantPool.h
Diff
Modified: trunk/Source/_javascript_Core/CMakeLists.txt (262038 => 262039)
--- trunk/Source/_javascript_Core/CMakeLists.txt 2020-05-22 00:20:29 UTC (rev 262038)
+++ trunk/Source/_javascript_Core/CMakeLists.txt 2020-05-22 00:39:30 UTC (rev 262039)
@@ -464,7 +464,6 @@
assembler/AbortReason.h
assembler/AbstractMacroAssembler.h
assembler/AssemblerBuffer.h
-assembler/AssemblerBufferWithConstantPool.h
assembler/AssemblerCommon.h
assembler/CPU.h
assembler/CodeLocation.h
Modified: trunk/Source/_javascript_Core/ChangeLog (262038 => 262039)
--- trunk/Source/_javascript_Core/ChangeLog 2020-05-22 00:20:29 UTC (rev 262038)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-05-22 00:39:30 UTC (rev 262039)
@@ -1,3 +1,14 @@
+2020-05-21 Robin Morisset
+
+Remove AssemblerBufferWithConstantPool.h (as it has been dead for years)
+https://bugs.webkit.org/show_bug.cgi?id=212241
+
+Reviewed by Yusuke Suzuki.
+
+* CMakeLists.txt:
+* _javascript_Core.xcodeproj/project.pbxproj:
+* assembler/AssemblerBufferWithConstantPool.h: Removed.
+
2020-05-21 Alexey Shvayka
Use @isUndefinedOrNull instead of abstract equality with null
Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (262038 => 262039)
--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2020-05-22 00:20:29 UTC (rev 262038)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2020-05-22 00:39:30 UTC (rev 262039)
@@ -269,7 +269,7 @@
0F2D4DEA19832DAC007D4B19 /* TypeLocation.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F2D4DE719832DAC007D4B19 /* TypeLocation.h */; settings = {ATTRIBUTES = (Private, ); }; };
0F2D4DEC19832DC4007D4B19 /* TypeProfilerLog.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F2D4DE019832D91007D4B19 /* TypeProfilerLog.h */; settings = {ATTRIBUTES = (Private, ); }; };
0F2D4DF019832DD6007D4B19 /* TypeSet.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F2D4DE419832D91007D4B19 /* TypeSet.h */; settings = {ATTRIBUTES = (Private, ); }; };
-0F2DD8121AB3D8BE00BBB8E8 /* DFGArgumentsEliminationPhase.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F2DD80D1AB3D8BE00BBB8E8 /* DFGArgumentsEliminationPhase.h */; };
+ 0F2DD8121AB3D8BE00BBB8E8 /* DFGArgumentsEliminationPhase.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F2DD80D1AB3D8BE00BBB8E8 /* DFGArgumentsEliminationPhase.h */; };
0F2DD8141AB3D8BE00BBB8E8 /* DFGArgumentsUtilities.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F2DD80F1AB3D8BE00BBB8E8 /* DFGArgumentsUtilities.h */; };
0F2DD8151AB3D8BE00BBB8E8 /* DFGForAllKills.h in Headers */ = {isa = PBXBuildFile; fileRef = 0F2DD8101AB3D8BE00BBB8E8 /* DFGForAllKills.h */; };
0F2E892C16D028AD009E4FD2 /* UnusedPointer.h in Headers */ = {isa = PBXBuildFile; fileRef = 65987F2F16828A7E003C2F8D /* UnusedPointer.h */; settings = {ATTRIBUTES = (Private, ); }; };
@@ -1265,7 +1265,6 @@
86CC85A10EE79A4700288682 /* JITInlines.h in Headers */ = {isa = PBXBuildFile; fileRef = 86CC85A00EE79A4700288682 /* JITInlines.h */; };
86CCEFDE0F413F8900FD7F9E /* JITCode.h in Headers */ = {isa = PBXBuildFile; fileRef = 86CCEFDD0F413F8900FD7F9E /* JITCode.h */; settings = {ATTRIBUTES = (Private, ); }; };
86D2221A167EF9440024C804 /* testapi.mm in Sources */ = {isa = PBXBuildFile; fileRef = 86D22219167EF9440024C804 /* testapi.mm */; };
- 86D3B2C510156BDE002865E7 /* AssemblerBufferWithConstantPool.h in Headers */ = {isa = PBXBuildFile; fileRef = 86D3B2C110156BDE002865E7 /* AssemblerBufferWithConstantPool.h */; settings = {ATTRIBUTES = (Private, ); }; };
86D3B3C310159D7F002865E7 /* LinkBuffer.h in Headers */ = {isa = PBXBuildFile; fileRef = 86D3B3C110159D7F002865E7 /* LinkBuffer.h */; settings = {ATTRIBUTES = (Private, ); }; };
86E116B10FE75AC800B512BC /* CodeLocation.h in Headers */ = {isa = PBXBuildFile; fileRef = 86E116B00FE75AC800B512BC /* CodeLocation.h */; settings = {ATTRIBUTES = (Private, ); }; };
86E3C612167BABD7006D760A /* JSValue.h in Headers */ = {isa = PBXBuildFile; fileRef = 86E3C606167BAB87006D760A /* JSValue.h */; settings = {ATTRIBUTES = (Public, ); }; };
@@ -2454,7 +2453,7 @@
0F2D4DE519832DAC007D4B19 /* ToThisStatus.cpp */ = {isa =
[webkit-changes] [261596] trunk
Title: [261596] trunk
Revision 261596
Author rmoris...@apple.com
Date 2020-05-12 20:09:50 -0700 (Tue, 12 May 2020)
Log Message
Exception check for OOM is a bit too late in JSBigInt::exponentiate.
https://bugs.webkit.org/show_bug.cgi?id=211823
Reviewed by Mark Lam.
JSTests:
Just add one more case so that this test now catches this bug (the control-flow through JSBigInt::exponentiate is pretty convoluted).
* stress/bigint-exponential-oom.js:
(shouldThrow):
Source/_javascript_Core:
We were doing multiplyImpl(...).payload.asHeapBigInt(), but multiplyImpl can return a null payload if it causes an exception.
So we must first check whether an exception was raised, and only if not can we do asHeapBigInt.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::exponentiateImpl):
Modified Paths
trunk/JSTests/ChangeLog
trunk/JSTests/stress/bigint-exponential-oom.js
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/JSBigInt.cpp
Diff
Modified: trunk/JSTests/ChangeLog (261595 => 261596)
--- trunk/JSTests/ChangeLog 2020-05-13 03:04:58 UTC (rev 261595)
+++ trunk/JSTests/ChangeLog 2020-05-13 03:09:50 UTC (rev 261596)
@@ -1,3 +1,15 @@
+2020-05-12 Robin Morisset
+
+Exception check for OOM is a bit too late in JSBigInt::exponentiate.
+https://bugs.webkit.org/show_bug.cgi?id=211823
+
+Reviewed by Mark Lam.
+
+Just add one more case so that this test now catches this bug (the control-flow through JSBigInt::exponentiate is pretty convoluted).
+
+* stress/bigint-exponential-oom.js:
+(shouldThrow):
+
2020-05-12 Saam Barati
handling of Check in VarargsForwardingPhase is too pessimistic
Modified: trunk/JSTests/stress/bigint-exponential-oom.js (261595 => 261596)
--- trunk/JSTests/stress/bigint-exponential-oom.js 2020-05-13 03:04:58 UTC (rev 261595)
+++ trunk/JSTests/stress/bigint-exponential-oom.js 2020-05-13 03:09:50 UTC (rev 261596)
@@ -28,3 +28,6 @@
shouldThrow(() => {
2n ** 0xfffn;
}, `Error: Out of memory: BigInt generated from this operation is too big`);
+shouldThrow(() => {
+10n ** 100n;
+}, `Error: Out of memory: BigInt generated from this operation is too big`);
Modified: trunk/Source/_javascript_Core/ChangeLog (261595 => 261596)
--- trunk/Source/_javascript_Core/ChangeLog 2020-05-13 03:04:58 UTC (rev 261595)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-05-13 03:09:50 UTC (rev 261596)
@@ -1,3 +1,16 @@
+2020-05-12 Robin Morisset
+
+Exception check for OOM is a bit too late in JSBigInt::exponentiate.
+https://bugs.webkit.org/show_bug.cgi?id=211823
+
+Reviewed by Mark Lam.
+
+We were doing multiplyImpl(...).payload.asHeapBigInt(), but multiplyImpl can return a null payload if it causes an exception.
+So we must first check whether an exception was raised, and only if not can we do asHeapBigInt.
+
+* runtime/JSBigInt.cpp:
+(JSC::JSBigInt::exponentiateImpl):
+
2020-05-12 Saam Barati
handling of Check in VarargsForwardingPhase is too pessimistic
Modified: trunk/Source/_javascript_Core/runtime/JSBigInt.cpp (261595 => 261596)
--- trunk/Source/_javascript_Core/runtime/JSBigInt.cpp 2020-05-13 03:04:58 UTC (rev 261595)
+++ trunk/Source/_javascript_Core/runtime/JSBigInt.cpp 2020-05-13 03:09:50 UTC (rev 261596)
@@ -482,15 +482,21 @@
n >>= 1;
for (; n; n >>= 1) {
-JSBigInt* maybeResult = JSBigInt::multiplyImpl(globalObject, HeapBigIntImpl { runningSquare }, HeapBigIntImpl { runningSquare }).payload.asHeapBigInt();
+ImplResult temp = JSBigInt::multiplyImpl(globalObject, HeapBigIntImpl { runningSquare }, HeapBigIntImpl { runningSquare });
RETURN_IF_EXCEPTION(scope, nullptr);
+ASSERT(temp.payload);
+ASSERT(temp.payload.isHeapBigInt());
+JSBigInt* maybeResult = temp.payload.asHeapBigInt();
runningSquare = maybeResult;
if (n & 1) {
if (!result)
result = runningSquare;
else {
-maybeResult = JSBigInt::multiplyImpl(globalObject, HeapBigIntImpl { result }, HeapBigIntImpl { runningSquare }).payload.asHeapBigInt();
+temp = JSBigInt::multiplyImpl(globalObject, HeapBigIntImpl { result }, HeapBigIntImpl { runningSquare });
RETURN_IF_EXCEPTION(scope, nullptr);
+ASSERT(temp.payload);
+ASSERT(temp.payload.isHeapBigInt());
+maybeResult = temp.payload.asHeapBigInt();
result = maybeResult;
}
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [260165] trunk/Source
Title: [260165] trunk/Source
Revision 260165
Author rmoris...@apple.com
Date 2020-04-15 18:40:42 -0700 (Wed, 15 Apr 2020)
Log Message
Flaky Test: fetch/fetch-worker-crash.html
https://bugs.webkit.org/show_bug.cgi?id=187257
Reviewed by Yusuke Suzuki.
Source/_javascript_Core:
The crash is coming from setExceptionPorts which is inlined in WTF::registerThreadForMachExceptionHandling.
>From the error message we know that the problem is an "invalid port right".
http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_set_exception_ports.html tells us that the "port right" is the third parameter to thread_set_exception_ports, which is exceptionPort in our case.
exceptionPort is a global variable defined at the top of Signals.cpp:
static mach_port_t exceptionPort;
It is set in exactly one place:
kern_return_t kr = mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, );
in a std::call_once, in startMachExceptionHandlerThread().
Note that startMachExceptionHandlerThread() is called from the main thread just before the point where we are stuck.. and there is no synchronization to make sure it completed and its effect is visible to the worker thread before it uses exceptionPort.
So I think the crash is due to this race between allocating exceptionPort and using it, resulting in an invalid exceptionPort being sometimes passed to the kernel.
So this patch is a simple speculative fix, by running startMachExceptionHandlerThread() in initializeThreading(), before JSLock()::lock() can be run.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
Source/WTF:
Make startMachExceptionHandlerThread visible so that we can make sure it is called whenever initializing JSC.
* wtf/threads/Signals.cpp:
(WTF::startMachExceptionHandlerThread):
* wtf/threads/Signals.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/InitializeThreading.cpp
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/threads/Signals.cpp
trunk/Source/WTF/wtf/threads/Signals.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (260164 => 260165)
--- trunk/Source/_javascript_Core/ChangeLog 2020-04-16 00:31:17 UTC (rev 260164)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-04-16 01:40:42 UTC (rev 260165)
@@ -1,3 +1,27 @@
+2020-04-15 Robin Morisset
+
+Flaky Test: fetch/fetch-worker-crash.html
+https://bugs.webkit.org/show_bug.cgi?id=187257
+
+
+Reviewed by Yusuke Suzuki.
+
+The crash is coming from setExceptionPorts which is inlined in WTF::registerThreadForMachExceptionHandling.
+From the error message we know that the problem is an "invalid port right".
+http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_set_exception_ports.html tells us that the "port right" is the third parameter to thread_set_exception_ports, which is exceptionPort in our case.
+exceptionPort is a global variable defined at the top of Signals.cpp:
+ static mach_port_t exceptionPort;
+It is set in exactly one place:
+ kern_return_t kr = mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, );
+in a std::call_once, in startMachExceptionHandlerThread().
+Note that startMachExceptionHandlerThread() is called from the main thread just before the point where we are stuck.. and there is no synchronization to make sure it completed and its effect is visible to the worker thread before it uses exceptionPort.
+
+So I think the crash is due to this race between allocating exceptionPort and using it, resulting in an invalid exceptionPort being sometimes passed to the kernel.
+So this patch is a simple speculative fix, by running startMachExceptionHandlerThread() in initializeThreading(), before JSLock()::lock() can be run.
+
+* runtime/InitializeThreading.cpp:
+(JSC::initializeThreading):
+
2020-04-15 Ross Kirsling
Unreviewed build fix for r260161.
Modified: trunk/Source/_javascript_Core/runtime/InitializeThreading.cpp (260164 => 260165)
--- trunk/Source/_javascript_Core/runtime/InitializeThreading.cpp 2020-04-16 00:31:17 UTC (rev 260164)
+++ trunk/Source/_javascript_Core/runtime/InitializeThreading.cpp 2020-04-16 01:40:42 UTC (rev 260165)
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
namespace JSC {
@@ -99,6 +100,11 @@
if (VM::isInMiniMode())
WTF::fastEnableMiniMode();
+
+#if HAVE(MACH_EXCEPTIONS)
+// JSLock::lock() can call registerThreadForMachExceptionHandling() which crashes if this has not been called first.
+WTF::startMachExceptionHandlerThread();
+#endif
});
}
Modified: trunk/Source/WTF/ChangeLog (260164 => 260165)
--- trunk/Source/WTF/ChangeLog 2020-04-16 00:31:17 UTC (rev 260164)
+++ trunk/Source/WTF/ChangeLog 2020-04-16 01:40:42 UTC (rev 260165)
@@ -1,3 +1,17 @@
+2020-04-15 Robin Morisset
+
+Flaky Test: fetch/fetch-worker-crash.html
+
[webkit-changes] [256087] trunk/Source/JavaScriptCore
Title: [256087] trunk/Source/_javascript_Core
Revision 256087
Author rmoris...@apple.com
Date 2020-02-07 22:08:33 -0800 (Fri, 07 Feb 2020)
Log Message
Throw OutOfMemory exception instead of crashing if DirectArguments/ScopedArguments can't be created
https://bugs.webkit.org/show_bug.cgi?id=207423
Reviewed by Mark Lam.
AllocationFailureMode::Assert is problematic because fuzzers keep producing spurious error reports when they generate code that tries allocating infinite amount of memory.
The right approach is to use AllocationFailureMode::ReturnNull, and throw a JS exception upon receiving null.
In this patch I fixed two functions that were using AllocationFailureMode::Assert:
DirectArguments::DirectArguments::overrideThings
GenericArguments::initModifiedArgumentsDescriptor
No test added, because the only test we have is highly non-deterministic/flaky (only triggers about 10 to 20% of the time even before the fix).
* runtime/DirectArguments.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments::deletePropertyByIndex):
(JSC::GenericArguments::defineOwnProperty):
(JSC::GenericArguments::initModifiedArgumentsDescriptor):
(JSC::GenericArguments::initModifiedArgumentsDescriptorIfNecessary):
(JSC::GenericArguments::setModifiedArgumentDescriptor):
* runtime/ScopedArguments.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp
trunk/Source/_javascript_Core/runtime/DirectArguments.cpp
trunk/Source/_javascript_Core/runtime/DirectArguments.h
trunk/Source/_javascript_Core/runtime/GenericArguments.h
trunk/Source/_javascript_Core/runtime/GenericArgumentsInlines.h
trunk/Source/_javascript_Core/runtime/ScopedArguments.cpp
trunk/Source/_javascript_Core/runtime/ScopedArguments.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (256086 => 256087)
--- trunk/Source/_javascript_Core/ChangeLog 2020-02-08 04:21:21 UTC (rev 256086)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-02-08 06:08:33 UTC (rev 256087)
@@ -1,3 +1,29 @@
+2020-02-07 Robin Morisset
+
+Throw OutOfMemory exception instead of crashing if DirectArguments/ScopedArguments can't be created
+https://bugs.webkit.org/show_bug.cgi?id=207423
+
+Reviewed by Mark Lam.
+
+AllocationFailureMode::Assert is problematic because fuzzers keep producing spurious error reports when they generate code that tries allocating infinite amount of memory.
+The right approach is to use AllocationFailureMode::ReturnNull, and throw a JS exception upon receiving null.
+
+In this patch I fixed two functions that were using AllocationFailureMode::Assert:
+DirectArguments::DirectArguments::overrideThings
+GenericArguments::initModifiedArgumentsDescriptor
+
+No test added, because the only test we have is highly non-deterministic/flaky (only triggers about 10 to 20% of the time even before the fix).
+
+* runtime/DirectArguments.h:
+* runtime/GenericArguments.h:
+* runtime/GenericArgumentsInlines.h:
+(JSC::GenericArguments::deletePropertyByIndex):
+(JSC::GenericArguments::defineOwnProperty):
+(JSC::GenericArguments::initModifiedArgumentsDescriptor):
+(JSC::GenericArguments::initModifiedArgumentsDescriptorIfNecessary):
+(JSC::GenericArguments::setModifiedArgumentDescriptor):
+* runtime/ScopedArguments.h:
+
2020-02-07 Ryan Haddad
Unreviewed, rolling out r256051.
Modified: trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp (256086 => 256087)
--- trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp 2020-02-08 04:21:21 UTC (rev 256086)
+++ trunk/Source/_javascript_Core/runtime/CommonSlowPaths.cpp 2020-02-08 06:08:33 UTC (rev 256087)
@@ -987,6 +987,7 @@
CHECK_EXCEPTION();
couldDelete = baseObject->methodTable(vm)->deleteProperty(baseObject, globalObject, property);
}
+CHECK_EXCEPTION();
if (!couldDelete && codeBlock->isStrictMode())
THROW(createTypeError(globalObject, UnableToDeletePropertyError));
Modified: trunk/Source/_javascript_Core/runtime/DirectArguments.cpp (256086 => 256087)
--- trunk/Source/_javascript_Core/runtime/DirectArguments.cpp 2020-02-08 04:21:21 UTC (rev 256086)
+++ trunk/Source/_javascript_Core/runtime/DirectArguments.cpp 2020-02-08 06:08:33 UTC (rev 256087)
@@ -110,15 +110,22 @@
return Structure::create(vm, globalObject, prototype, TypeInfo(DirectArgumentsType, StructureFlags), info());
}
-void DirectArguments::overrideThings(VM& vm)
+void DirectArguments::overrideThings(JSGlobalObject* globalObject)
{
+VM& vm = globalObject->vm();
+auto scope = DECLARE_THROW_SCOPE(vm);
+
RELEASE_ASSERT(!m_mappedArguments);
putDirect(vm, vm.propertyNames->length, jsNumber(m_length), static_cast(PropertyAttribute::DontEnum));
putDirect(vm, vm.propertyNames->callee, m_callee.get(),
[webkit-changes] [256003] trunk/Source/JavaScriptCore
Title: [256003] trunk/Source/_javascript_Core Revision 256003 Author rmoris...@apple.com Date 2020-02-06 19:12:32 -0800 (Thu, 06 Feb 2020) Log Message Most of B3 and Air does not need to include CCallHelpers.h https://bugs.webkit.org/show_bug.cgi?id=206975 Reviewed by Mark Lam. They only do to use CCallHelpers::Jump or CCallHelpers::Label. But CCallHelpers inherit those from MacroAssembler. And MacroAssembler.h is dramatically cheaper to include (since CCallHelpers includes AssemblyHelpers which includes CodeBlock.h which includes roughly the entire runtime). * b3/B3CheckSpecial.cpp: * b3/B3CheckSpecial.h: * b3/B3LowerMacros.cpp: * b3/B3PatchpointSpecial.cpp: (JSC::B3::PatchpointSpecial::generate): * b3/B3PatchpointSpecial.h: * b3/B3StackmapGenerationParams.cpp: (JSC::B3::StackmapGenerationParams::successorLabels const): * b3/B3StackmapGenerationParams.h: * b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: * b3/air/AirCCallSpecial.cpp: * b3/air/AirCCallSpecial.h: * b3/air/AirCode.cpp: * b3/air/AirCode.h: (JSC::B3::Air::Code::entrypointLabel const): * b3/air/AirCustom.cpp: (JSC::B3::Air::CCallCustom::generate): (JSC::B3::Air::ShuffleCustom::generate): (JSC::B3::Air::WasmBoundsCheckCustom::generate): * b3/air/AirCustom.h: (JSC::B3::Air::PatchCustom::generate): (JSC::B3::Air::EntrySwitchCustom::generate): * b3/air/AirDisassembler.cpp: (JSC::B3::Air::Disassembler::addInst): * b3/air/AirDisassembler.h: * b3/air/AirGenerationContext.h: * b3/air/AirInst.h: * b3/air/AirPrintSpecial.cpp: (JSC::B3::Air::PrintSpecial::generate): * b3/air/AirPrintSpecial.h: * b3/air/AirSpecial.h: * b3/air/AirValidate.cpp: * b3/air/opcode_generator.rb: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/B3CheckSpecial.cpp trunk/Source/_javascript_Core/b3/B3CheckSpecial.h trunk/Source/_javascript_Core/b3/B3EliminateCommonSubexpressions.cpp trunk/Source/_javascript_Core/b3/B3MemoryValue.h trunk/Source/_javascript_Core/b3/B3PatchpointSpecial.cpp trunk/Source/_javascript_Core/b3/B3PatchpointSpecial.h trunk/Source/_javascript_Core/b3/B3StackmapGenerationParams.cpp trunk/Source/_javascript_Core/b3/B3StackmapGenerationParams.h trunk/Source/_javascript_Core/b3/B3StackmapValue.h trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersAndStackAndGenerateCode.h trunk/Source/_javascript_Core/b3/air/AirCCallSpecial.cpp trunk/Source/_javascript_Core/b3/air/AirCCallSpecial.h trunk/Source/_javascript_Core/b3/air/AirCode.cpp trunk/Source/_javascript_Core/b3/air/AirCode.h trunk/Source/_javascript_Core/b3/air/AirCustom.cpp trunk/Source/_javascript_Core/b3/air/AirCustom.h trunk/Source/_javascript_Core/b3/air/AirDisassembler.cpp trunk/Source/_javascript_Core/b3/air/AirDisassembler.h trunk/Source/_javascript_Core/b3/air/AirGenerationContext.h trunk/Source/_javascript_Core/b3/air/AirInst.h trunk/Source/_javascript_Core/b3/air/AirPhaseScope.cpp trunk/Source/_javascript_Core/b3/air/AirPrintSpecial.cpp trunk/Source/_javascript_Core/b3/air/AirPrintSpecial.h trunk/Source/_javascript_Core/b3/air/AirSpecial.h trunk/Source/_javascript_Core/b3/air/AirValidate.cpp trunk/Source/_javascript_Core/b3/air/opcode_generator.rb Diff Modified: trunk/Source/_javascript_Core/ChangeLog (256002 => 256003) --- trunk/Source/_javascript_Core/ChangeLog 2020-02-07 03:08:39 UTC (rev 256002) +++ trunk/Source/_javascript_Core/ChangeLog 2020-02-07 03:12:32 UTC (rev 256003) @@ -1,3 +1,47 @@ +2020-02-06 Robin Morisset + +Most of B3 and Air does not need to include CCallHelpers.h +https://bugs.webkit.org/show_bug.cgi?id=206975 + +Reviewed by Mark Lam. + +They only do to use CCallHelpers::Jump or CCallHelpers::Label. +But CCallHelpers inherit those from MacroAssembler. And MacroAssembler.h is dramatically cheaper to include (since CCallHelpers includes AssemblyHelpers which includes CodeBlock.h which includes roughly the entire runtime). + +* b3/B3CheckSpecial.cpp: +* b3/B3CheckSpecial.h: +* b3/B3LowerMacros.cpp: +* b3/B3PatchpointSpecial.cpp: +(JSC::B3::PatchpointSpecial::generate): +* b3/B3PatchpointSpecial.h: +* b3/B3StackmapGenerationParams.cpp: +(JSC::B3::StackmapGenerationParams::successorLabels const): +* b3/B3StackmapGenerationParams.h: +* b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: +* b3/air/AirCCallSpecial.cpp: +* b3/air/AirCCallSpecial.h: +* b3/air/AirCode.cpp: +* b3/air/AirCode.h: +(JSC::B3::Air::Code::entrypointLabel const): +* b3/air/AirCustom.cpp: +(JSC::B3::Air::CCallCustom::generate): +(JSC::B3::Air::ShuffleCustom::generate): +(JSC::B3::Air::WasmBoundsCheckCustom::generate): +* b3/air/AirCustom.h: +(JSC::B3::Air::PatchCustom::generate): +(JSC::B3::Air::EntrySwitchCustom::generate): +* b3/air/AirDisassembler.cpp: +(JSC::B3::Air::Disassembler::addInst): +*
[webkit-changes] [255406] trunk/Source
Title: [255406] trunk/Source Revision 255406 Author rmoris...@apple.com Date 2020-01-29 17:06:08 -0800 (Wed, 29 Jan 2020) Log Message Remove Options::enableSpectreMitigations https://bugs.webkit.org/show_bug.cgi?id=193885 Reviewed by Saam Barati. >From what I remember we decided to remove the spectre-specific mitigations we had tried (in favor of things like process-per-origin). I don't think anyone is using the SpectreGadget we had added for experiments either. So this patch removes the following three options, and all the code that depended on them: - enableSpectreMitigations (was true, only used in one place) - enableSpectreGadgets (was false) - zeroStackFrame (was false, and was an experiment about Spectre variant 4 if I remember correctly) Source/_javascript_Core: * b3/air/AirCode.cpp: (JSC::B3::Air::defaultPrologueGenerator): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::compile): (JSC::DFG::JITCompiler::compileFunction): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileCurrentBlock): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::lower): * jit/AssemblyHelpers.h: * jit/JIT.cpp: (JSC::JIT::compileWithoutLinking): * runtime/OptionsList.h: * wasm/WasmB3IRGenerator.cpp: (JSC::Wasm::B3IRGenerator::addCallIndirect): * yarr/YarrJIT.cpp: (JSC::Yarr::YarrGenerator::initCallFrame): Source/WebCore: No new tests as there is no new behaviour added. * CMakeLists.txt: * DerivedSources-input.xcfilelist: * DerivedSources-output.xcfilelist: * DerivedSources.make: * Sources.txt: * WebCore.xcodeproj/project.pbxproj: * bindings/js/WebCoreBuiltinNames.h: * dom/SpectreGadget.cpp: Removed. * dom/SpectreGadget.h: Removed. * dom/SpectreGadget.idl: Removed. * page/RuntimeEnabledFeatures.cpp: * page/RuntimeEnabledFeatures.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/air/AirCode.cpp trunk/Source/_javascript_Core/dfg/DFGJITCompiler.cpp trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp trunk/Source/_javascript_Core/ftl/FTLLowerDFGToB3.cpp trunk/Source/_javascript_Core/jit/AssemblyHelpers.h trunk/Source/_javascript_Core/jit/JIT.cpp trunk/Source/_javascript_Core/runtime/OptionsList.h trunk/Source/_javascript_Core/wasm/WasmB3IRGenerator.cpp trunk/Source/_javascript_Core/yarr/YarrJIT.cpp trunk/Source/WebCore/CMakeLists.txt trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/DerivedSources-input.xcfilelist trunk/Source/WebCore/DerivedSources-output.xcfilelist trunk/Source/WebCore/DerivedSources.make trunk/Source/WebCore/Sources.txt trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj trunk/Source/WebCore/bindings/js/WebCoreBuiltinNames.h trunk/Source/WebCore/page/RuntimeEnabledFeatures.cpp trunk/Source/WebCore/page/RuntimeEnabledFeatures.h Removed Paths trunk/Source/WebCore/dom/SpectreGadget.cpp trunk/Source/WebCore/dom/SpectreGadget.h trunk/Source/WebCore/dom/SpectreGadget.idl Diff Modified: trunk/Source/_javascript_Core/ChangeLog (255405 => 255406) --- trunk/Source/_javascript_Core/ChangeLog 2020-01-30 01:02:17 UTC (rev 255405) +++ trunk/Source/_javascript_Core/ChangeLog 2020-01-30 01:06:08 UTC (rev 255406) @@ -1,3 +1,35 @@ +2020-01-29 Robin Morisset + +Remove Options::enableSpectreMitigations +https://bugs.webkit.org/show_bug.cgi?id=193885 + +Reviewed by Saam Barati. + +From what I remember we decided to remove the spectre-specific mitigations we had tried (in favor of things like process-per-origin). +I don't think anyone is using the SpectreGadget we had added for experiments either. +So this patch removes the following three options, and all the code that depended on them: +- enableSpectreMitigations (was true, only used in one place) +- enableSpectreGadgets (was false) +- zeroStackFrame (was false, and was an experiment about Spectre variant 4 if I remember correctly) + +* b3/air/AirCode.cpp: +(JSC::B3::Air::defaultPrologueGenerator): +* dfg/DFGJITCompiler.cpp: +(JSC::DFG::JITCompiler::compile): +(JSC::DFG::JITCompiler::compileFunction): +* dfg/DFGSpeculativeJIT.cpp: +(JSC::DFG::SpeculativeJIT::compileCurrentBlock): +* ftl/FTLLowerDFGToB3.cpp: +(JSC::FTL::DFG::LowerDFGToB3::lower): +* jit/AssemblyHelpers.h: +* jit/JIT.cpp: +(JSC::JIT::compileWithoutLinking): +* runtime/OptionsList.h: +* wasm/WasmB3IRGenerator.cpp: +(JSC::Wasm::B3IRGenerator::addCallIndirect): +* yarr/YarrJIT.cpp: +(JSC::Yarr::YarrGenerator::initCallFrame): + 2020-01-29 Devin Rousso Web Inspector: add instrumentation for showing existing Web Animations Modified: trunk/Source/_javascript_Core/b3/air/AirCode.cpp (255405 => 255406) --- trunk/Source/_javascript_Core/b3/air/AirCode.cpp 2020-01-30 01:02:17 UTC (rev 255405) +++ trunk/Source/_javascript_Core/b3/air/AirCode.cpp 2020-01-30 01:06:08 UTC (rev 255406) @@ -46,8 +46,6 @@
[webkit-changes] [255394] trunk/Source/JavaScriptCore
Title: [255394] trunk/Source/_javascript_Core
Revision 255394
Author rmoris...@apple.com
Date 2020-01-29 15:35:32 -0800 (Wed, 29 Jan 2020)
Log Message
Don't include CCallHelpers.h in B3Procedure.h
https://bugs.webkit.org/show_bug.cgi?id=206966
Reviewed by Saam Barati.
I verified through -ftime-trace and it massively speeds up a few of the compilation units (e.g. UnifiedSource10.cpp).
* b3/B3Procedure.cpp:
* b3/B3Procedure.h:
* b3/testb3_6.cpp:
(testEntrySwitchSimple):
(testEntrySwitchNoEntrySwitch):
(testEntrySwitchWithCommonPaths):
(testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
(testEntrySwitchLoop):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* wasm/WasmParser.h:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3Procedure.cpp
trunk/Source/_javascript_Core/b3/B3Procedure.h
trunk/Source/_javascript_Core/b3/testb3_6.cpp
trunk/Source/_javascript_Core/ftl/FTLCompile.cpp
trunk/Source/_javascript_Core/wasm/WasmParser.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (255393 => 255394)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-29 23:14:36 UTC (rev 255393)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-29 23:35:32 UTC (rev 255394)
@@ -1,3 +1,24 @@
+2020-01-29 Robin Morisset
+
+Don't include CCallHelpers.h in B3Procedure.h
+https://bugs.webkit.org/show_bug.cgi?id=206966
+
+Reviewed by Saam Barati.
+
+I verified through -ftime-trace and it massively speeds up a few of the compilation units (e.g. UnifiedSource10.cpp).
+
+* b3/B3Procedure.cpp:
+* b3/B3Procedure.h:
+* b3/testb3_6.cpp:
+(testEntrySwitchSimple):
+(testEntrySwitchNoEntrySwitch):
+(testEntrySwitchWithCommonPaths):
+(testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
+(testEntrySwitchLoop):
+* ftl/FTLCompile.cpp:
+(JSC::FTL::compile):
+* wasm/WasmParser.h:
+
2020-01-29 Justin Michaud
Fix small memory regression caused by r206365
Modified: trunk/Source/_javascript_Core/b3/B3Procedure.cpp (255393 => 255394)
--- trunk/Source/_javascript_Core/b3/B3Procedure.cpp 2020-01-29 23:14:36 UTC (rev 255393)
+++ trunk/Source/_javascript_Core/b3/B3Procedure.cpp 2020-01-29 23:35:32 UTC (rev 255394)
@@ -349,11 +349,6 @@
return m_fastConstants.contains(constant);
}
-CCallHelpers::Label Procedure::entrypointLabel(unsigned index) const
-{
-return m_code->entrypointLabel(index);
-}
-
void* Procedure::addDataSection(size_t size)
{
if (!size)
Modified: trunk/Source/_javascript_Core/b3/B3Procedure.h (255393 => 255394)
--- trunk/Source/_javascript_Core/b3/B3Procedure.h 2020-01-29 23:14:36 UTC (rev 255393)
+++ trunk/Source/_javascript_Core/b3/B3Procedure.h 2020-01-29 23:35:32 UTC (rev 255394)
@@ -33,7 +33,6 @@
#include "B3SparseCollection.h"
#include "B3Type.h"
#include "B3ValueKey.h"
-#include "CCallHelpers.h"
#include "PureNaN.h"
#include "RegisterAtOffsetList.h"
#include
@@ -46,8 +45,12 @@
#include
#include
-namespace JSC { namespace B3 {
+namespace JSC {
+class CCallHelpers;
+
+namespace B3 {
+
class BackwardsCFG;
class BackwardsDominators;
class BasicBlock;
@@ -197,11 +200,6 @@
unsigned numEntrypoints() const { return m_numEntrypoints; }
JS_EXPORT_PRIVATE void setNumEntrypoints(unsigned);
-// Only call this after code generation is complete. Note that the label for the 0th entrypoint
-// should point to exactly where the code generation cursor was before you started generating
-// code.
-JS_EXPORT_PRIVATE CCallHelpers::Label entrypointLabel(unsigned entrypointIndex) const;
-
// The name has to be a string literal, since we don't do any memory management for the string.
void setLastPhaseName(const char* name)
{
Modified: trunk/Source/_javascript_Core/b3/testb3_6.cpp (255393 => 255394)
--- trunk/Source/_javascript_Core/b3/testb3_6.cpp 2020-01-29 23:14:36 UTC (rev 255393)
+++ trunk/Source/_javascript_Core/b3/testb3_6.cpp 2020-01-29 23:35:32 UTC (rev 255394)
@@ -1936,9 +1936,9 @@
CCallHelpers jit;
generate(proc, jit);
LinkBuffer linkBuffer(jit, nullptr);
-CodeLocationLabel labelOne = linkBuffer.locationOf(proc.entrypointLabel(0));
-CodeLocationLabel labelTwo = linkBuffer.locationOf(proc.entrypointLabel(1));
-CodeLocationLabel labelThree = linkBuffer.locationOf(proc.entrypointLabel(2));
+CodeLocationLabel labelOne = linkBuffer.locationOf(proc.code().entrypointLabel(0));
+CodeLocationLabel labelTwo = linkBuffer.locationOf(proc.code().entrypointLabel(1));
+CodeLocationLabel labelThree = linkBuffer.locationOf(proc.code().entrypointLabel(2));
MacroAssemblerCodeRef codeRef = FINALIZE_CODE(linkBuffer, B3CompilationPtrTag, "testb3 compilation");
@@ -1969,9 +1969,9 @@
CCallHelpers jit;
generate(proc, jit);
LinkBuffer linkBuffer(jit, nullptr);
-CodeLocationLabel labelOne =
[webkit-changes] [255321] trunk/Source/JavaScriptCore
Title: [255321] trunk/Source/_javascript_Core
Revision 255321
Author rmoris...@apple.com
Date 2020-01-28 16:22:17 -0800 (Tue, 28 Jan 2020)
Log Message
Remove the include of BytecodeGenerator.h in CodeCache.h
https://bugs.webkit.org/show_bug.cgi?id=206851
Reviewed by Tadeu Zagallo.
This reduces the number of times that BytecodeStructs.h has to be parsed from 33 to 25 times, and unblocks https://bugs.webkit.org/show_bug.cgi?id=206720.
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockForFunctions):
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::generateUnlinkedCodeBlock):
(JSC::generateUnlinkedCodeBlockForDirectEval):
(JSC::recursivelyGenerateUnlinkedCodeBlockForProgram):
(JSC::recursivelyGenerateUnlinkedCodeBlockForModuleProgram):
* runtime/CodeCache.h:
* runtime/Completion.cpp:
(JSC::generateProgramBytecode):
(JSC::generateModuleBytecode):
* runtime/DirectEvalExecutable.cpp:
(JSC::DirectEvalExecutable::create):
* runtime/JSGlobalObject.cpp:
* runtime/VM.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/CodeCache.cpp
trunk/Source/_javascript_Core/runtime/CodeCache.h
trunk/Source/_javascript_Core/runtime/Completion.cpp
trunk/Source/_javascript_Core/runtime/DirectEvalExecutable.cpp
trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp
trunk/Source/_javascript_Core/runtime/VM.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (255320 => 255321)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-29 00:06:26 UTC (rev 255320)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-29 00:22:17 UTC (rev 255321)
@@ -1,3 +1,28 @@
+2020-01-28 Robin Morisset
+
+Remove the include of BytecodeGenerator.h in CodeCache.h
+https://bugs.webkit.org/show_bug.cgi?id=206851
+
+Reviewed by Tadeu Zagallo.
+
+This reduces the number of times that BytecodeStructs.h has to be parsed from 33 to 25 times, and unblocks https://bugs.webkit.org/show_bug.cgi?id=206720.
+
+* runtime/CodeCache.cpp:
+(JSC::generateUnlinkedCodeBlockForFunctions):
+(JSC::generateUnlinkedCodeBlockImpl):
+(JSC::generateUnlinkedCodeBlock):
+(JSC::generateUnlinkedCodeBlockForDirectEval):
+(JSC::recursivelyGenerateUnlinkedCodeBlockForProgram):
+(JSC::recursivelyGenerateUnlinkedCodeBlockForModuleProgram):
+* runtime/CodeCache.h:
+* runtime/Completion.cpp:
+(JSC::generateProgramBytecode):
+(JSC::generateModuleBytecode):
+* runtime/DirectEvalExecutable.cpp:
+(JSC::DirectEvalExecutable::create):
+* runtime/JSGlobalObject.cpp:
+* runtime/VM.cpp:
+
2020-01-28 Mark Lam
Some website needs more stack space.
Modified: trunk/Source/_javascript_Core/runtime/CodeCache.cpp (255320 => 255321)
--- trunk/Source/_javascript_Core/runtime/CodeCache.cpp 2020-01-29 00:06:26 UTC (rev 255320)
+++ trunk/Source/_javascript_Core/runtime/CodeCache.cpp 2020-01-29 00:22:17 UTC (rev 255321)
@@ -26,6 +26,7 @@
#include "config.h"
#include "CodeCache.h"
+#include "BytecodeGenerator.h"
#include "IndirectEvalExecutable.h"
#include
@@ -50,7 +51,101 @@
}
}
+static void generateUnlinkedCodeBlockForFunctions(VM& vm, UnlinkedCodeBlock* unlinkedCodeBlock, const SourceCode& parentSource, OptionSet codeGenerationMode, ParserError& error)
+{
+auto generate = [&](UnlinkedFunctionExecutable* unlinkedExecutable, CodeSpecializationKind constructorKind) {
+if (constructorKind == CodeForConstruct && SourceParseModeSet(SourceParseMode::AsyncArrowFunctionMode, SourceParseMode::AsyncMethodMode, SourceParseMode::AsyncFunctionMode).contains(unlinkedExecutable->parseMode()))
+return;
+
+SourceCode source = unlinkedExecutable->linkedSourceCode(parentSource);
+UnlinkedFunctionCodeBlock* unlinkedFunctionCodeBlock = unlinkedExecutable->unlinkedCodeBlockFor(vm, source, constructorKind, codeGenerationMode, error, unlinkedExecutable->parseMode());
+if (unlinkedFunctionCodeBlock)
+generateUnlinkedCodeBlockForFunctions(vm, unlinkedFunctionCodeBlock, source, codeGenerationMode, error);
+};
+
+// FIXME: We should also generate CodeBlocks for CodeForConstruct
+// https://bugs.webkit.org/show_bug.cgi?id=193823
+for (unsigned i = 0; i < unlinkedCodeBlock->numberOfFunctionDecls(); i++)
+generate(unlinkedCodeBlock->functionDecl(i), CodeForCall);
+for (unsigned i = 0; i < unlinkedCodeBlock->numberOfFunctionExprs(); i++)
+generate(unlinkedCodeBlock->functionExpr(i), CodeForCall);
+}
+
+template
+UnlinkedCodeBlockType* generateUnlinkedCodeBlockImpl(VM& vm, const SourceCode& source, JSParserStrictMode strictMode, JSParserScriptMode scriptMode, OptionSet codeGenerationMode, ParserError& error, EvalContextType evalContextType, DerivedContextType derivedContextType, bool isArrowFunctionContext, const VariableEnvironment* variablesUnderTDZ, ExecutableType* executable = nullptr)
+{
+
[webkit-changes] [255160] trunk/Tools
Title: [255160] trunk/Tools
Revision 255160
Author rmoris...@apple.com
Date 2020-01-27 12:18:45 -0800 (Mon, 27 Jan 2020)
Log Message
Tools/Scripts/set-webkit-configuration should accept --coverage/--no-coverage
https://bugs.webkit.org/show_bug.cgi?id=206833
Reviewed by Jonathan Bedard.
Just a trivial fix to the arguments validation code of the script.
* Scripts/set-webkit-configuration:
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/Scripts/set-webkit-configuration
Diff
Modified: trunk/Tools/ChangeLog (255159 => 255160)
--- trunk/Tools/ChangeLog 2020-01-27 20:07:23 UTC (rev 255159)
+++ trunk/Tools/ChangeLog 2020-01-27 20:18:45 UTC (rev 255160)
@@ -1,3 +1,14 @@
+2020-01-27 Robin Morisset
+
+Tools/Scripts/set-webkit-configuration should accept --coverage/--no-coverage
+https://bugs.webkit.org/show_bug.cgi?id=206833
+
+Reviewed by Jonathan Bedard.
+
+Just a trivial fix to the arguments validation code of the script.
+
+* Scripts/set-webkit-configuration:
+
2020-01-27 Said Abou-Hallawa
Throttling requestAnimationFrame should be controlled by RenderingUpdateScheduler
Modified: trunk/Tools/Scripts/set-webkit-configuration (255159 => 255160)
--- trunk/Tools/Scripts/set-webkit-configuration 2020-01-27 20:07:23 UTC (rev 255159)
+++ trunk/Tools/Scripts/set-webkit-configuration 2020-01-27 20:18:45 UTC (rev 255160)
@@ -86,7 +86,9 @@
exit 0;
}
-if ((!$configuration && !$architecture && !$enableASAN && !$disableASAN && !$ltoMode && !$forceOptimizationLevel) || ($enableASAN && $disableASAN)) {
+if ((!$configuration && !$architecture && !$enableASAN && !$disableASAN && !$enableCoverage && !$disableCoverage && !$ltoMode && !$forceOptimizationLevel)
+|| ($enableASAN && $disableASAN)
+|| ($enableCoverage && $disableCoverage)) {
print STDERR $usage;
exit 1;
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [255052] trunk/Source/JavaScriptCore
Title: [255052] trunk/Source/_javascript_Core
Revision 255052
Author rmoris...@apple.com
Date 2020-01-23 20:52:29 -0800 (Thu, 23 Jan 2020)
Log Message
Break the dependency between jsc and DerivedSources
https://bugs.webkit.org/show_bug.cgi?id=206720
Reviewed by Mark Lam.
According to Tadeu, the slowdown of production builds (by more than 20%) when he landed his bytecode patch was caused by a new dependency of the jsc binary on DerivedSources/, which was needed because of DerivedSources/BytecodeStructs.h being included in CommonSlowPaths.h which is transitively included in jsc.cpp.
Now that BytecodeStructs.h is no longer included in CommonSlowPaths.h (see https://bugs.webkit.org/show_bug.cgi?id=206566), I'm trying to break the dependency, to recover from this compile time regression.
* Configurations/JSC.xcconfig:
* _javascript_Core.xcodeproj/project.pbxproj:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/Configurations/JSC.xcconfig
trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (255051 => 255052)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-24 04:24:50 UTC (rev 255051)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-24 04:52:29 UTC (rev 255052)
@@ -1,5 +1,18 @@
2020-01-23 Robin Morisset
+Break the dependency between jsc and DerivedSources
+https://bugs.webkit.org/show_bug.cgi?id=206720
+
+Reviewed by Mark Lam.
+
+According to Tadeu, the slowdown of production builds (by more than 20%) when he landed his bytecode patch was caused by a new dependency of the jsc binary on DerivedSources/, which was needed because of DerivedSources/BytecodeStructs.h being included in CommonSlowPaths.h which is transitively included in jsc.cpp.
+Now that BytecodeStructs.h is no longer included in CommonSlowPaths.h (see https://bugs.webkit.org/show_bug.cgi?id=206566), I'm trying to break the dependency, to recover from this compile time regression.
+
+* Configurations/JSC.xcconfig:
+* _javascript_Core.xcodeproj/project.pbxproj:
+
+2020-01-23 Robin Morisset
+
Remove dead option useFTLTBAA
https://bugs.webkit.org/show_bug.cgi?id=206725
Modified: trunk/Source/_javascript_Core/Configurations/JSC.xcconfig (255051 => 255052)
--- trunk/Source/_javascript_Core/Configurations/JSC.xcconfig 2020-01-24 04:24:50 UTC (rev 255051)
+++ trunk/Source/_javascript_Core/Configurations/JSC.xcconfig 2020-01-24 04:52:29 UTC (rev 255052)
@@ -37,4 +37,3 @@
// Explicitly add the PrivateHeaders directory to the search path so that generated header files can be found in production builds.
HEADER_SEARCH_PATHS = "$(_javascript_CORE_FRAMEWORKS_DIR)/_javascript_Core.framework/PrivateHeaders" $(inherited);
-HEADER_SEARCH_PATHS = "${BUILT_PRODUCTS_DIR}/DerivedSources/_javascript_Core" $(HEADER_SEARCH_PATHS);
Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (255051 => 255052)
--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2020-01-24 04:24:50 UTC (rev 255051)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2020-01-24 04:52:29 UTC (rev 255052)
@@ -2087,13 +2087,6 @@
remoteGlobalIDString = E1AC2E2720F7B94C00B0897D;
remoteInfo = "Unlock Keychain";
};
- 14D9D9D9218462B5009126C2 /* PBXContainerItemProxy */ = {
- isa = PBXContainerItemProxy;
- containerPortal = 0867D690FE84028FC02AAC07 /* Project object */;
- proxyType = 1;
- remoteGlobalIDString = 65FB3F6609D11E9100F49DEB;
- remoteInfo = "Derived Sources";
- };
52CD0F652242F5A3004A18A5 /* PBXContainerItemProxy */ = {
isa = PBXContainerItemProxy;
containerPortal = 0867D690FE84028FC02AAC07 /* Project object */;
@@ -10623,7 +10616,6 @@
buildRules = (
);
dependencies = (
-14D9D9DA218462B5009126C2 /* PBXTargetDependency */,
);
name = jsc;
productInstallPath = /usr/local/bin;
@@ -11433,11 +11425,6 @@
target = E1AC2E2720F7B94C00B0897D /* Unlock Keychain */;
targetProxy = 14CFB11823035F6900F0048C /* PBXContainerItemProxy */;
};
- 14D9D9DA218462B5009126C2 /* PBXTargetDependency */ = {
- isa = PBXTargetDependency;
- target = 65FB3F6609D11E9100F49DEB /* Derived Sources */;
- targetProxy = 14D9D9D9218462B5009126C2 /* PBXContainerItemProxy */;
- };
52CD0F662242F5A3004A18A5 /* PBXTargetDependency */ = {
isa = PBXTargetDependency;
target = 52CD0F592242F569004A18A5 /* testdfg */;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [255051] trunk/Source/JavaScriptCore
Title: [255051] trunk/Source/_javascript_Core Revision 255051 Author rmoris...@apple.com Date 2020-01-23 20:24:50 -0800 (Thu, 23 Jan 2020) Log Message Remove dead option useFTLTBAA https://bugs.webkit.org/show_bug.cgi?id=206725 Reviewed by Mark Lam. It is likely from when the FTL used LLVM, before B3/Air were written, making this option completely obsolete (and it is currently unused). * runtime/OptionsList.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/runtime/OptionsList.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (255050 => 255051) --- trunk/Source/_javascript_Core/ChangeLog 2020-01-24 03:18:55 UTC (rev 255050) +++ trunk/Source/_javascript_Core/ChangeLog 2020-01-24 04:24:50 UTC (rev 255051) @@ -1,5 +1,16 @@ 2020-01-23 Robin Morisset +Remove dead option useFTLTBAA +https://bugs.webkit.org/show_bug.cgi?id=206725 + +Reviewed by Mark Lam. + +It is likely from when the FTL used LLVM, before B3/Air were written, making this option completely obsolete (and it is currently unused). + +* runtime/OptionsList.h: + +2020-01-23 Robin Morisset + Remove dead options "dumpAllDFGNodes"/"showAllDFGNodes" https://bugs.webkit.org/show_bug.cgi?id=204372 Modified: trunk/Source/_javascript_Core/runtime/OptionsList.h (255050 => 255051) --- trunk/Source/_javascript_Core/runtime/OptionsList.h 2020-01-24 03:18:55 UTC (rev 255050) +++ trunk/Source/_javascript_Core/runtime/OptionsList.h 2020-01-24 04:24:50 UTC (rev 255051) @@ -215,7 +215,6 @@ v(Bool, useOSREntryToFTL, true, Normal, nullptr) \ \ v(Bool, useFTLJIT, true, Normal, "allows the FTL JIT to be used if true") \ -v(Bool, useFTLTBAA, true, Normal, nullptr) \ v(Bool, validateFTLOSRExitLiveness, false, Normal, nullptr) \ v(Unsigned, defaultB3OptLevel, 2, Normal, nullptr) \ v(Bool, b3AlwaysFailsBeforeCompile, false, Normal, nullptr) \ ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [255048] trunk/Source/JavaScriptCore
Title: [255048] trunk/Source/_javascript_Core Revision 255048 Author rmoris...@apple.com Date 2020-01-23 18:57:12 -0800 (Thu, 23 Jan 2020) Log Message Remove dead options "dumpAllDFGNodes"/"showAllDFGNodes" https://bugs.webkit.org/show_bug.cgi?id=204372 Reviewed by Keith Miller. * runtime/OptionsList.h: Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/runtime/OptionsList.h Diff Modified: trunk/Source/_javascript_Core/ChangeLog (255047 => 255048) --- trunk/Source/_javascript_Core/ChangeLog 2020-01-24 02:54:37 UTC (rev 255047) +++ trunk/Source/_javascript_Core/ChangeLog 2020-01-24 02:57:12 UTC (rev 255048) @@ -1,3 +1,12 @@ +2020-01-23 Robin Morisset + +Remove dead options "dumpAllDFGNodes"/"showAllDFGNodes" +https://bugs.webkit.org/show_bug.cgi?id=204372 + +Reviewed by Keith Miller. + +* runtime/OptionsList.h: + 2020-01-23 Saam Barati Get rid of didFinishParsing and make parseInner return its results Modified: trunk/Source/_javascript_Core/runtime/OptionsList.h (255047 => 255048) --- trunk/Source/_javascript_Core/runtime/OptionsList.h 2020-01-24 02:54:37 UTC (rev 255047) +++ trunk/Source/_javascript_Core/runtime/OptionsList.h 2020-01-24 02:57:12 UTC (rev 255048) @@ -128,7 +128,6 @@ v(Bool, dumpWasmDisassembly, false, Normal, "dumps disassembly of all Wasm code upon compilation") \ v(Bool, dumpBBQDisassembly, false, Normal, "dumps disassembly of BBQ Wasm code upon compilation") \ v(Bool, dumpOMGDisassembly, false, Normal, "dumps disassembly of OMG Wasm code upon compilation") \ -v(Bool, dumpAllDFGNodes, false, Normal, nullptr) \ v(Bool, logJITCodeForPerf, false, Configurable, nullptr) \ v(OptionRange, bytecodeRangeToJITCompile, 0, Normal, "bytecode size range to allow compilation on, e.g. 1:100") \ v(OptionRange, bytecodeRangeToDFGCompile, 0, Normal, "bytecode size range to allow DFG compilation on, e.g. 1:100") \ @@ -510,7 +509,6 @@ v(showDisassembly, dumpDisassembly, SameOption) \ v(showDFGDisassembly, dumpDFGDisassembly, SameOption) \ v(showFTLDisassembly, dumpFTLDisassembly, SameOption) \ -v(showAllDFGNodes, dumpAllDFGNodes, SameOption) \ v(alwaysDoFullCollection, useGenerationalGC, InvertedOption) \ v(enableOSREntryToDFG, useOSREntryToDFG, SameOption) \ v(enableOSREntryToFTL, useOSREntryToFTL, SameOption) \ ___ webkit-changes mailing list webkit-changes@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [255040] trunk/Source/JavaScriptCore
Title: [255040] trunk/Source/_javascript_Core
Revision 255040
Author rmoris...@apple.com
Date 2020-01-23 15:25:32 -0800 (Thu, 23 Jan 2020)
Log Message
Don't include BytecodeStructs.h in CommonSlowPaths.h
https://bugs.webkit.org/show_bug.cgi?id=206566
Reviewed by Tadeu Zagallo.
Simple improvement to compile times.
* _javascript_Core.xcodeproj/project.pbxproj:
* dfg/DFGOSREntry.cpp:
* jit/JIT.h:
* jit/JITInlines.h:
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
* runtime/CommonSlowPaths.h:
* wasm/WasmSlowPaths.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj
trunk/Source/_javascript_Core/dfg/DFGOSREntry.cpp
trunk/Source/_javascript_Core/jit/JIT.h
trunk/Source/_javascript_Core/jit/JITInlines.h
trunk/Source/_javascript_Core/jit/JITOperations.cpp
trunk/Source/_javascript_Core/llint/LLIntSlowPaths.cpp
trunk/Source/_javascript_Core/runtime/CommonSlowPaths.h
trunk/Source/_javascript_Core/wasm/WasmSlowPaths.cpp
Added Paths
trunk/Source/_javascript_Core/runtime/CommonSlowPathsInlines.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (255039 => 255040)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-23 22:49:15 UTC (rev 255039)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-23 23:25:32 UTC (rev 255040)
@@ -1,3 +1,21 @@
+2020-01-23 Robin Morisset
+
+Don't include BytecodeStructs.h in CommonSlowPaths.h
+https://bugs.webkit.org/show_bug.cgi?id=206566
+
+Reviewed by Tadeu Zagallo.
+
+Simple improvement to compile times.
+
+* _javascript_Core.xcodeproj/project.pbxproj:
+* dfg/DFGOSREntry.cpp:
+* jit/JIT.h:
+* jit/JITInlines.h:
+* jit/JITOperations.cpp:
+* llint/LLIntSlowPaths.cpp:
+* runtime/CommonSlowPaths.h:
+* wasm/WasmSlowPaths.cpp:
+
2020-01-23 Saam Barati
OptimizeAssociativeExpressionTrees should reset value owners before running
Modified: trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj (255039 => 255040)
--- trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2020-01-23 22:49:15 UTC (rev 255039)
+++ trunk/Source/_javascript_Core/_javascript_Core.xcodeproj/project.pbxproj 2020-01-23 23:25:32 UTC (rev 255040)
@@ -867,6 +867,7 @@
2AF7382D18BBBF92008A5A37 /* StructureIDTable.h in Headers */ = {isa = PBXBuildFile; fileRef = 2AF7382B18BBBF92008A5A37 /* StructureIDTable.h */; settings = {ATTRIBUTES = (Private, ); }; };
2D342F36F7244096804ADB24 /* SourceOrigin.h in Headers */ = {isa = PBXBuildFile; fileRef = 425BA1337E4344E1B269A671 /* SourceOrigin.h */; settings = {ATTRIBUTES = (Private, ); }; };
3395C70722555F6D00BDBFAD /* B3EliminateDeadCode.h in Headers */ = {isa = PBXBuildFile; fileRef = 3395C70522555F6D00BDBFAD /* B3EliminateDeadCode.h */; };
+ 33A920BD23DA2C6D000EBAF0 /* CommonSlowPathsInlines.h in Headers */ = {isa = PBXBuildFile; fileRef = 33A920BC23DA2C6D000EBAF0 /* CommonSlowPathsInlines.h */; settings = {ATTRIBUTES = (Private, ); }; };
33B2A54722653481005A0F79 /* B3ValueInlines.h in Headers */ = {isa = PBXBuildFile; fileRef = 0FEC84FB1BDACDAC0080FF74 /* B3ValueInlines.h */; };
33B2A548226543BF005A0F79 /* FTLLowerDFGToB3.cpp in Sources */ = {isa = PBXBuildFile; fileRef = 0FEA0A04170513DB00BB722C /* FTLLowerDFGToB3.cpp */; };
371D842D17C98B6E00ECF994 /* libz.dylib in Frameworks */ = {isa = PBXBuildFile; fileRef = 371D842C17C98B6E00ECF994 /* libz.dylib */; };
@@ -3508,6 +3509,7 @@
3374364A224D79EF00C8C227 /* B3OptimizeAssociativeExpressionTrees.h */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.h; name = B3OptimizeAssociativeExpressionTrees.h; path = b3/B3OptimizeAssociativeExpressionTrees.h; sourceTree = ""; };
3395C70422555F6C00BDBFAD /* B3EliminateDeadCode.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; name = B3EliminateDeadCode.cpp; path = b3/B3EliminateDeadCode.cpp; sourceTree = ""; };
3395C70522555F6D00BDBFAD /* B3EliminateDeadCode.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = B3EliminateDeadCode.h; path = b3/B3EliminateDeadCode.h; sourceTree = ""; };
+ 33A920BC23DA2C6D000EBAF0 /* CommonSlowPathsInlines.h */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = CommonSlowPathsInlines.h; sourceTree = ""; };
33B2A54522651D53005A0F79 /* MarkedSpace.cpp */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.cpp.cpp; path = MarkedSpace.cpp; sourceTree = ""; };
37119A7720CCB5DC002C6DC9 /* WebKitTargetConditionals.xcconfig */ = {isa = PBXFileReference; lastKnownFileType = text.xcconfig; path = WebKitTargetConditionals.xcconfig; sourceTree = ""; };
371D842C17C98B6E00ECF994 /* libz.dylib */ = {isa = PBXFileReference; lastKnownFileType = "compiled.mach-o.dylib"; name = libz.dylib; path = usr/lib/libz.dylib; sourceTree = SDKROOT; };
@@ -4834,10
[webkit-changes] [254738] trunk
Title: [254738] trunk
Revision 254738
Author rmoris...@apple.com
Date 2020-01-16 23:16:34 -0800 (Thu, 16 Jan 2020)
Log Message
[ESNext] Enables a way to throw an error on ByteCodeGenerator step
https://bugs.webkit.org/show_bug.cgi?id=180139
Reviewed by Mark Lam.
JSTests:
* stress/eval-huge-big-int-memory-overflow.js: Added.
Source/_javascript_Core:
This is a minimal fix that only deals with overly huge BigInts.
A more thorough solution is rather low priority (since it has neither securities nor performance impact).
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addBigIntConstant):
* bytecompiler/NodesCodegen.cpp:
(JSC::ConstantNode::emitBytecode):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::parseInt):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp
trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp
trunk/Source/_javascript_Core/runtime/JSBigInt.cpp
Added Paths
trunk/JSTests/stress/eval-huge-big-int-memory-overflow.js
Diff
Modified: trunk/JSTests/ChangeLog (254737 => 254738)
--- trunk/JSTests/ChangeLog 2020-01-17 06:59:15 UTC (rev 254737)
+++ trunk/JSTests/ChangeLog 2020-01-17 07:16:34 UTC (rev 254738)
@@ -1,3 +1,12 @@
+2020-01-16 Robin Morisset
+
+[ESNext] Enables a way to throw an error on ByteCodeGenerator step
+https://bugs.webkit.org/show_bug.cgi?id=180139
+
+Reviewed by Mark Lam.
+
+* stress/eval-huge-big-int-memory-overflow.js: Added.
+
2020-01-16 Keith Miller
Reland bytecode checkpoints since bugs have been fixed
Added: trunk/JSTests/stress/eval-huge-big-int-memory-overflow.js (0 => 254738)
--- trunk/JSTests/stress/eval-huge-big-int-memory-overflow.js (rev 0)
+++ trunk/JSTests/stress/eval-huge-big-int-memory-overflow.js 2020-01-17 07:16:34 UTC (rev 254738)
@@ -0,0 +1,5 @@
+//@ if $memoryLimited then skip else runDefault end
+
+try {
+eval('1'.repeat(2**20)+'n');
+} catch {}
Modified: trunk/Source/_javascript_Core/ChangeLog (254737 => 254738)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-17 06:59:15 UTC (rev 254737)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-17 07:16:34 UTC (rev 254738)
@@ -1,3 +1,20 @@
+2020-01-16 Robin Morisset
+
+[ESNext] Enables a way to throw an error on ByteCodeGenerator step
+https://bugs.webkit.org/show_bug.cgi?id=180139
+
+Reviewed by Mark Lam.
+
+This is a minimal fix that only deals with overly huge BigInts.
+A more thorough solution is rather low priority (since it has neither securities nor performance impact).
+
+* bytecompiler/BytecodeGenerator.cpp:
+(JSC::BytecodeGenerator::addBigIntConstant):
+* bytecompiler/NodesCodegen.cpp:
+(JSC::ConstantNode::emitBytecode):
+* runtime/JSBigInt.cpp:
+(JSC::JSBigInt::parseInt):
+
2020-01-16 Keith Miller
Reland bytecode checkpoints since bugs have been fixed
Modified: trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp (254737 => 254738)
--- trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp 2020-01-17 06:59:15 UTC (rev 254737)
+++ trunk/Source/_javascript_Core/bytecompiler/BytecodeGenerator.cpp 2020-01-17 07:16:34 UTC (rev 254738)
@@ -2880,10 +2880,7 @@
auto scope = DECLARE_CATCH_SCOPE(vm());
auto parseIntSign = sign ? JSBigInt::ParseIntSign::Signed : JSBigInt::ParseIntSign::Unsigned;
JSBigInt* bigIntInMap = JSBigInt::parseInt(nullptr, vm(), identifier.string(), radix, JSBigInt::ErrorParseMode::ThrowExceptions, parseIntSign);
-// FIXME: [ESNext] Enables a way to throw an error on ByteCodeGenerator step
-// https://bugs.webkit.org/show_bug.cgi?id=180139
scope.assertNoException();
-RELEASE_ASSERT(bigIntInMap);
addConstantValue(bigIntInMap);
return bigIntInMap;
Modified: trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp (254737 => 254738)
--- trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp 2020-01-17 06:59:15 UTC (rev 254737)
+++ trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp 2020-01-17 07:16:34 UTC (rev 254738)
@@ -119,7 +119,12 @@
{
if (dst == generator.ignoredResult())
return 0;
-return generator.emitLoad(dst, jsValue(generator));
+JSValue constant = jsValue(generator);
+if (UNLIKELY(!constant)) {
+// This can happen if we try to parse a string or BigInt so enormous that we OOM.
+return generator.emitThrowExpressionTooDeepException();
+}
+return generator.emitLoad(dst, constant);
}
JSValue StringNode::jsValue(BytecodeGenerator& generator) const
Modified: trunk/Source/_javascript_Core/runtime/JSBigInt.cpp (254737 => 254738)
--- trunk/Source/_javascript_Core/runtime/JSBigInt.cpp 2020-01-17 06:59:15 UTC (rev 254737)
+++ trunk/Source/_javascript_Core/runtime/JSBigInt.cpp 2020-01-17 07:16:34
[webkit-changes] [254717] trunk/Source/JavaScriptCore
Title: [254717] trunk/Source/_javascript_Core
Revision 254717
Author rmoris...@apple.com
Date 2020-01-16 16:06:35 -0800 (Thu, 16 Jan 2020)
Log Message
Try to simplify the template deduction used by callOperation in DFGSpeculativeJIT
https://bugs.webkit.org/show_bug.cgi?id=206329
Reviewed by Keith Miller.
The change is very simple: stop using NoResultTag in callOperation, since it is redundant with !FunctionTraits::hasResult
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutAccessorById):
(JSC::DFG::SpeculativeJIT::compilePutGetterSetterById):
(JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
(JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
(JSC::DFG::SpeculativeJIT::compileDefineDataProperty):
(JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty):
(JSC::DFG::SpeculativeJIT::compilePutByIdWithThis):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::callOperation):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.h
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT32_64.cpp
trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT64.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (254716 => 254717)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-16 23:53:19 UTC (rev 254716)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-17 00:06:35 UTC (rev 254717)
@@ -1,5 +1,31 @@
2020-01-16 Robin Morisset
+Try to simplify the template deduction used by callOperation in DFGSpeculativeJIT
+https://bugs.webkit.org/show_bug.cgi?id=206329
+
+Reviewed by Keith Miller.
+
+The change is very simple: stop using NoResultTag in callOperation, since it is redundant with !FunctionTraits::hasResult
+
+* dfg/DFGSlowPathGenerator.h:
+(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate):
+* dfg/DFGSpeculativeJIT.cpp:
+(JSC::DFG::SpeculativeJIT::compilePutAccessorById):
+(JSC::DFG::SpeculativeJIT::compilePutGetterSetterById):
+(JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
+(JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
+(JSC::DFG::SpeculativeJIT::compileDefineDataProperty):
+(JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty):
+(JSC::DFG::SpeculativeJIT::compilePutByIdWithThis):
+* dfg/DFGSpeculativeJIT.h:
+(JSC::DFG::SpeculativeJIT::callOperation):
+* dfg/DFGSpeculativeJIT32_64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+* dfg/DFGSpeculativeJIT64.cpp:
+(JSC::DFG::SpeculativeJIT::compile):
+
+2020-01-16 Robin Morisset
+
Teach the bytecode that arithmetic operations can return bigints
https://bugs.webkit.org/show_bug.cgi?id=205416
Modified: trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h (254716 => 254717)
--- trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h 2020-01-16 23:53:19 UTC (rev 254716)
+++ trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h 2020-01-17 00:06:35 UTC (rev 254717)
@@ -173,7 +173,10 @@
void unpackAndGenerate(SpeculativeJIT* jit, std::index_sequence)
{
this->setUp(jit);
-this->recordCall(jit->callOperation(this->m_function, extractResult(this->m_result), std::get(m_arguments)...));
+if constexpr (std::is_same::value)
+this->recordCall(jit->callOperation(this->m_function, std::get(m_arguments)...));
+else
+this->recordCall(jit->callOperation(this->m_function, extractResult(this->m_result), std::get(m_arguments)...));
this->tearDown(jit);
}
Modified: trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp (254716 => 254717)
--- trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2020-01-16 23:53:19 UTC (rev 254716)
+++ trunk/Source/_javascript_Core/dfg/DFGSpeculativeJIT.cpp 2020-01-17 00:06:35 UTC (rev 254717)
@@ -11247,7 +11247,7 @@
GPRReg accessorGPR = accessor.gpr();
flushRegisters();
-callOperation(node->op() == PutGetterById ? operationPutGetterById : operationPutSetterById, NoResult, TrustedImmPtr::weakPointer(m_graph, m_graph.globalObjectFor(node->origin.semantic)), baseGPR, identifierUID(node->identifierNumber()), node->accessorAttributes(), accessorGPR);
+callOperation(node->op() == PutGetterById ? operationPutGetterById : operationPutSetterById, TrustedImmPtr::weakPointer(m_graph, m_graph.globalObjectFor(node->origin.semantic)), baseGPR, identifierUID(node->identifierNumber()), node->accessorAttributes(), accessorGPR);
m_jit.exceptionCheck();
noResult(node);
@@ -11265,7 +11265,7 @@
[webkit-changes] [254716] trunk
Title: [254716] trunk
Revision 254716
Author rmoris...@apple.com
Date 2020-01-16 15:53:19 -0800 (Thu, 16 Jan 2020)
Log Message
Teach the bytecode that arithmetic operations can return bigints
https://bugs.webkit.org/show_bug.cgi?id=205416
Reviewed by Yusuke Suzuki.
JSTests:
This file crashes in debug mode without the fix.
* stress/big-int-arithmetic-return-big-int.js: Added.
(fooAdd):
(fooSub):
(fooMul):
(fooDiv):
Source/_javascript_Core:
Add already has the correct ResultType, but previously Sub/Mult/Div/Mod/Pow/Negate were always claimed to return Number,
and when BigInt is enabled they can also return BigInt.
UnaryPlus is left unchanged as it is invalid on a BigInt (to keep asm.js working as intended).
* parser/NodeConstructors.h:
(JSC::NegateNode::NegateNode):
(JSC::PowNode::PowNode):
(JSC::MultNode::MultNode):
(JSC::DivNode::DivNode):
(JSC::ModNode::ModNode):
(JSC::SubNode::SubNode):
* parser/ResultType.h:
(JSC::ResultType::bigIntOrNumberType): Added.
(JSC::ResultType::forNonAddArith):
(JSC::ResultType::forUnaryArith):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/parser/NodeConstructors.h
trunk/Source/_javascript_Core/parser/ResultType.h
Added Paths
trunk/JSTests/stress/big-int-arithmetic-return-big-int.js
Diff
Modified: trunk/JSTests/ChangeLog (254715 => 254716)
--- trunk/JSTests/ChangeLog 2020-01-16 23:26:10 UTC (rev 254715)
+++ trunk/JSTests/ChangeLog 2020-01-16 23:53:19 UTC (rev 254716)
@@ -1,3 +1,18 @@
+2020-01-16 Robin Morisset
+
+Teach the bytecode that arithmetic operations can return bigints
+https://bugs.webkit.org/show_bug.cgi?id=205416
+
+Reviewed by Yusuke Suzuki.
+
+This file crashes in debug mode without the fix.
+
+* stress/big-int-arithmetic-return-big-int.js: Added.
+(fooAdd):
+(fooSub):
+(fooMul):
+(fooDiv):
+
2020-01-16 Mark Lam
operationToObject() should check for a null errorMessage.
Added: trunk/JSTests/stress/big-int-arithmetic-return-big-int.js (0 => 254716)
--- trunk/JSTests/stress/big-int-arithmetic-return-big-int.js (rev 0)
+++ trunk/JSTests/stress/big-int-arithmetic-return-big-int.js 2020-01-16 23:53:19 UTC (rev 254716)
@@ -0,0 +1,33 @@
+//@ runBigIntEnabled
+
+function fooAdd()
+{
+return (1n+1n) / 1;
+}
+function fooSub()
+{
+return (1n-1n) / 1;
+}
+function fooMul()
+{
+return (1n*1n) / 1;
+}
+function fooDiv()
+{
+return (1n/1n) / 1;
+}
+
+for (var i = 0; i < 1 ; ++i) {
+try {
+fooAdd()
+} catch {}
+try {
+fooSub()
+} catch {}
+try {
+fooMul()
+} catch {}
+try {
+fooDiv()
+} catch {}
+}
Modified: trunk/Source/_javascript_Core/ChangeLog (254715 => 254716)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-16 23:26:10 UTC (rev 254715)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-16 23:53:19 UTC (rev 254716)
@@ -1,5 +1,28 @@
2020-01-16 Robin Morisset
+Teach the bytecode that arithmetic operations can return bigints
+https://bugs.webkit.org/show_bug.cgi?id=205416
+
+Reviewed by Yusuke Suzuki.
+
+Add already has the correct ResultType, but previously Sub/Mult/Div/Mod/Pow/Negate were always claimed to return Number,
+and when BigInt is enabled they can also return BigInt.
+UnaryPlus is left unchanged as it is invalid on a BigInt (to keep asm.js working as intended).
+
+* parser/NodeConstructors.h:
+(JSC::NegateNode::NegateNode):
+(JSC::PowNode::PowNode):
+(JSC::MultNode::MultNode):
+(JSC::DivNode::DivNode):
+(JSC::ModNode::ModNode):
+(JSC::SubNode::SubNode):
+* parser/ResultType.h:
+(JSC::ResultType::bigIntOrNumberType): Added.
+(JSC::ResultType::forNonAddArith):
+(JSC::ResultType::forUnaryArith):
+
+2020-01-16 Robin Morisset
+
Use dataLogIf more regularly
https://bugs.webkit.org/show_bug.cgi?id=206332
Modified: trunk/Source/_javascript_Core/parser/NodeConstructors.h (254715 => 254716)
--- trunk/Source/_javascript_Core/parser/NodeConstructors.h 2020-01-16 23:26:10 UTC (rev 254715)
+++ trunk/Source/_javascript_Core/parser/NodeConstructors.h 2020-01-16 23:53:19 UTC (rev 254716)
@@ -516,6 +516,8 @@
{
}
+// UnaryPlus is guaranteed to always return a number, never a BigInt.
+// See https://tc39.es/ecma262/#sec-unary-plus-operator-runtime-semantics-evaluation
inline UnaryPlusNode::UnaryPlusNode(const JSTokenLocation& location, ExpressionNode* expr)
: UnaryOpNode(location, ResultType::numberType(), expr, op_to_number)
{
@@ -522,7 +524,7 @@
}
inline NegateNode::NegateNode(const JSTokenLocation& location, ExpressionNode* expr)
-: UnaryOpNode(location, ResultType::numberType(), expr, op_negate)
+: UnaryOpNode(location,
[webkit-changes] [254712] trunk/Source/JavaScriptCore
Title: [254712] trunk/Source/_javascript_Core
Revision 254712
Author rmoris...@apple.com
Date 2020-01-16 15:04:28 -0800 (Thu, 16 Jan 2020)
Log Message
Reduce the code generated by DFGSlowPathGenerator.h
https://bugs.webkit.org/show_bug.cgi?id=206330
Reviewed by Mark Lam.
The FunctionType parameter is only needed by CallResultAndArgumentsSlowPathGenerator, not by its base class CallSlowPathGenerator.
Moving it allows saving about 200kB from _javascript_Core (in Release mode), by reducing the number of instantiations of the methods of CallSlowPathGenerator.
* dfg/DFGSlowPathGenerator.h:
(JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::CallResultAndArgumentsSlowPathGenerator):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (254711 => 254712)
--- trunk/Source/_javascript_Core/ChangeLog 2020-01-16 22:57:43 UTC (rev 254711)
+++ trunk/Source/_javascript_Core/ChangeLog 2020-01-16 23:04:28 UTC (rev 254712)
@@ -1,3 +1,17 @@
+2020-01-16 Robin Morisset
+
+Reduce the code generated by DFGSlowPathGenerator.h
+https://bugs.webkit.org/show_bug.cgi?id=206330
+
+Reviewed by Mark Lam.
+
+The FunctionType parameter is only needed by CallResultAndArgumentsSlowPathGenerator, not by its base class CallSlowPathGenerator.
+Moving it allows saving about 200kB from _javascript_Core (in Release mode), by reducing the number of instantiations of the methods of CallSlowPathGenerator.
+
+* dfg/DFGSlowPathGenerator.h:
+(JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
+(JSC::DFG::CallResultAndArgumentsSlowPathGenerator::CallResultAndArgumentsSlowPathGenerator):
+
2020-01-16 Don Olmstead
Non-unified build fixes mid January 2020 edition
Modified: trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h (254711 => 254712)
--- trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h 2020-01-16 22:57:43 UTC (rev 254711)
+++ trunk/Source/_javascript_Core/dfg/DFGSlowPathGenerator.h 2020-01-16 23:04:28 UTC (rev 254712)
@@ -102,17 +102,16 @@
CheckNotNeeded
};
-template
+template
class CallSlowPathGenerator : public JumpingSlowPathGenerator {
public:
CallSlowPathGenerator(
-JumpType from, SpeculativeJIT* jit, FunctionType function,
+JumpType from, SpeculativeJIT* jit,
SpillRegistersMode spillMode, ExceptionCheckRequirement requirement, ResultType result)
: JumpingSlowPathGenerator(from, jit)
, m_spillMode(spillMode)
, m_exceptionCheckRequirement(requirement)
, m_result(result)
-, m_function(function)
{
if (m_spillMode == NeedToSpill)
jit->silentSpillAllRegistersImpl(false, m_plans, extractResult(result));
@@ -153,19 +152,18 @@
SpillRegistersMode m_spillMode;
ExceptionCheckRequirement m_exceptionCheckRequirement;
ResultType m_result;
-FunctionType m_function;
Vector m_plans;
};
template
class CallResultAndArgumentsSlowPathGenerator
-: public CallSlowPathGenerator {
+: public CallSlowPathGenerator {
public:
CallResultAndArgumentsSlowPathGenerator(
JumpType from, SpeculativeJIT* jit, FunctionType function,
SpillRegistersMode spillMode, ExceptionCheckRequirement requirement, ResultType result, Arguments... arguments)
-: CallSlowPathGenerator(
-from, jit, function, spillMode, requirement, result)
+: CallSlowPathGenerator(from, jit, spillMode, requirement, result)
+, m_function(function)
, m_arguments(std::forward(arguments)...)
{
}
@@ -184,6 +182,7 @@
unpackAndGenerate(jit, std::make_index_sequence>::value>());
}
+FunctionType m_function;
std::tuple m_arguments;
};
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [252699] trunk/Source/JavaScriptCore
Title: [252699] trunk/Source/_javascript_Core
Revision 252699
Author rmoris...@apple.com
Date 2019-11-20 12:06:52 -0800 (Wed, 20 Nov 2019)
Log Message
Fix load<16> on ARM64
https://bugs.webkit.org/show_bug.cgi?id=204326
Reviewed by Mark Lam.
On ARM64 I used load<16> in https://bugs.webkit.org/show_bug.cgi?id=202832.
Unfortunately it turns out to call ldr<16>, and ldr asserts that n is either 32 or 64.
This fix simply calls ldrh/strh directly.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::load16):
(JSC::MacroAssemblerARM64::store16):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (252698 => 252699)
--- trunk/Source/_javascript_Core/ChangeLog 2019-11-20 19:52:51 UTC (rev 252698)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-11-20 20:06:52 UTC (rev 252699)
@@ -1,3 +1,18 @@
+2019-11-20 Robin Morisset
+
+Fix load<16> on ARM64
+https://bugs.webkit.org/show_bug.cgi?id=204326
+
+Reviewed by Mark Lam.
+
+On ARM64 I used load<16> in https://bugs.webkit.org/show_bug.cgi?id=202832.
+Unfortunately it turns out to call ldr<16>, and ldr asserts that n is either 32 or 64.
+This fix simply calls ldrh/strh directly.
+
+* assembler/MacroAssemblerARM64.h:
+(JSC::MacroAssemblerARM64::load16):
+(JSC::MacroAssemblerARM64::store16):
+
2019-11-20 Mark Lam
Flaky JSC test: stress/stack-overflow-in-yarr-byteCompile.js.dfg-eager.
Modified: trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h (252698 => 252699)
--- trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h 2019-11-20 19:52:51 UTC (rev 252698)
+++ trunk/Source/_javascript_Core/assembler/MacroAssemblerARM64.h 2019-11-20 20:06:52 UTC (rev 252699)
@@ -1254,7 +1254,8 @@
void load16(const void* address, RegisterID dest)
{
-load<16>(address, dest);
+moveToCachedReg(TrustedImmPtr(address), cachedMemoryTempRegister());
+m_assembler.ldrh(dest, memoryTempRegister, 0);
}
void load16Unaligned(ImplicitAddress address, RegisterID dest)
@@ -1567,7 +1568,8 @@
void store16(RegisterID src, const void* address)
{
-store<16>(src, address);
+moveToCachedReg(TrustedImmPtr(address), cachedMemoryTempRegister());
+m_assembler.strh(src, memoryTempRegister, 0);
}
void store16(TrustedImm32 imm, const void* address)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [252680] trunk
Title: [252680] trunk Revision 252680 Author rmoris...@apple.com Date 2019-11-19 19:41:57 -0800 (Tue, 19 Nov 2019) Log Message [ESNext][BigInt] Add support for op_inc https://bugs.webkit.org/show_bug.cgi?id=193240 Reviewed by Yusuke Suzuki. JSTests: Some parts of these tests are inspired by tests in a WIP patch by Caio Lima. Thanks to him for allowing their reuse. * stress/inc-osr-exit-from-big-int.js: Added. (let.assert.sameValue): (postInc): (preInc): (postDec): (preDec): * stress/inc-osr-exit-to-big-int.js: Added. (let.assert.sameValue): (postInc): (preInc): (postDec): (preDec): (o.valueOf): Source/_javascript_Core: This patch adds support for both ++ and -- on BigInts. It required the following secondary changes: - teaching FixupPhase how to replace it by ArithAdd/ArithSub/ValueAdd/ValueSub when the type is Int32/Double/BigInt - pulling ObservedResults out of UnaryArithProfile/BinaryArithProfile, so that it can be used by ArithAdd regardless of whether it comes from an Inc or from an Add - adding the constant 1n to the VM object so that it can be used by FixupPhase since it cannot allocate a new JSValue. - adding an UnaryArithProfile to op_inc and op_dec, and teaching the llint to update them. - adding ToNumeric (identity on bigints, same as toNumber on everything else) to all tiers * bytecode/ArithProfile.cpp: (JSC::ArithProfile::shouldEmitSetDouble const): (JSC::ArithProfile::emitSetDouble const): (JSC::ArithProfile::shouldEmitSetNonNumeric const): (JSC::ArithProfile::shouldEmitSetBigInt const): (JSC::ArithProfile::emitSetNonNumeric const): (JSC::ArithProfile::emitSetBigInt const): * bytecode/ArithProfile.h: (JSC::ObservedResults::ObservedResults): (JSC::ObservedResults::didObserveNonInt32): (JSC::ObservedResults::didObserveDouble): (JSC::ObservedResults::didObserveNonNegZeroDouble): (JSC::ObservedResults::didObserveNegZeroDouble): (JSC::ObservedResults::didObserveNonNumeric): (JSC::ObservedResults::didObserveBigInt): (JSC::ObservedResults::didObserveInt32Overflow): (JSC::ObservedResults::didObserveInt52Overflow): (JSC::ArithProfile::observedResults const): (JSC::ArithProfile::didObserveNonInt32 const): (JSC::ArithProfile::didObserveDouble const): (JSC::ArithProfile::didObserveNonNegZeroDouble const): (JSC::ArithProfile::didObserveNegZeroDouble const): (JSC::ArithProfile::didObserveNonNumeric const): (JSC::ArithProfile::didObserveBigInt const): (JSC::ArithProfile::didObserveInt32Overflow const): (JSC::ArithProfile::didObserveInt52Overflow const): (JSC::ArithProfile::setObservedNonNegZeroDouble): (JSC::ArithProfile::setObservedNegZeroDouble): (JSC::ArithProfile::setObservedNonNumeric): (JSC::ArithProfile::setObservedBigInt): (JSC::ArithProfile::setObservedInt32Overflow): (JSC::ArithProfile::setObservedInt52Overflow): (JSC::ArithProfile::observeResult): * bytecode/BytecodeList.rb: * bytecode/BytecodeUseDef.h: (JSC::computeUsesForBytecodeIndex): (JSC::computeDefsForBytecodeIndex): * bytecode/CodeBlock.cpp: (JSC::CodeBlock::unaryArithProfileForPC): * bytecode/ExitKind.h: * bytecode/SpeculatedType.h: (JSC::isInt32SpeculationForArithmetic): (JSC::isInt32OrBooleanSpeculationForArithmetic): * bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::emitUnaryOp): (JSC::BytecodeGenerator::emitToNumeric): * bytecompiler/BytecodeGenerator.h: * bytecompiler/NodesCodegen.cpp: (JSC::emitPostIncOrDec): * dfg/DFGAbstractInterpreterInlines.h: (JSC::DFG::AbstractInterpreter::executeEffects): * dfg/DFGBackwardsPropagationPhase.cpp: (JSC::DFG::BackwardsPropagationPhase::propagate): * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::makeSafe): (JSC::DFG::ByteCodeParser::parseBlock): * dfg/DFGCapabilities.cpp: (JSC::DFG::capabilityLevel): * dfg/DFGClobberize.h: (JSC::DFG::clobberize): * dfg/DFGConstantFoldingPhase.cpp: (JSC::DFG::ConstantFoldingPhase::foldConstants): * dfg/DFGDoesGC.cpp: (JSC::DFG::doesGC): * dfg/DFGFixupPhase.cpp: (JSC::DFG::FixupPhase::fixupNode): (JSC::DFG::FixupPhase::fixupToNumeric): * dfg/DFGMayExit.cpp: * dfg/DFGNode.h: (JSC::DFG::Node::hasHeapPrediction): * dfg/DFGNodeType.h: * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPredictionPropagationPhase.cpp: * dfg/DFGSafeToExecute.h: (JSC::DFG::safeToExecute): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileIncOrDec): (JSC::DFG::SpeculativeJIT::compileToPrimitive): (JSC::DFG::SpeculativeJIT::compileToNumeric): * dfg/DFGSpeculativeJIT.h: * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * ftl/FTLCapabilities.cpp: (JSC::FTL::canCompile): * ftl/FTLLowerDFGToB3.cpp: (JSC::FTL::DFG::LowerDFGToB3::compileNode): (JSC::FTL::DFG::LowerDFGToB3::compileIncOrDec): * jit/JIT.cpp: (JSC::JIT::privateCompileMainPass): (JSC::JIT::privateCompileSlowCases): * jit/JIT.h: * jit/JITMathIC.h: (JSC::JITMathIC::generateInline): * jit/JITMulGenerator.cpp: (JSC::JITMulGenerator::generateFastPath): * jit/JITOpcodes.cpp:
[webkit-changes] [251966] trunk/Source/JavaScriptCore
Title: [251966] trunk/Source/_javascript_Core
Revision 251966
Author rmoris...@apple.com
Date 2019-11-02 13:12:38 -0700 (Sat, 02 Nov 2019)
Log Message
The offline assembler is wrong about which immediates are supported by and/or/xor on ARM64
https://bugs.webkit.org/show_bug.cgi?id=203752
Reviewed by Tadeu Zagallo.
See https://dinfuehr.github.io/blog/encoding-of-immediate-values-on-aarch64/ for the details of which immediates are supported.
This patch is a minimal fix, ideally we should refactor all of the code dealing with immediates in risc.rb, but considering that I don't know ruby and this code is poorly/not tested, I went for the simplest possible fix.
* offlineasm/arm64.rb:
* offlineasm/mips.rb:
* offlineasm/risc.rb:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/offlineasm/arm.rb
trunk/Source/_javascript_Core/offlineasm/arm64.rb
trunk/Source/_javascript_Core/offlineasm/mips.rb
trunk/Source/_javascript_Core/offlineasm/risc.rb
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (251965 => 251966)
--- trunk/Source/_javascript_Core/ChangeLog 2019-11-02 18:48:15 UTC (rev 251965)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-11-02 20:12:38 UTC (rev 251966)
@@ -1,3 +1,17 @@
+2019-11-02 Robin Morisset
+
+The offline assembler is wrong about which immediates are supported by and/or/xor on ARM64
+https://bugs.webkit.org/show_bug.cgi?id=203752
+
+Reviewed by Tadeu Zagallo.
+
+See https://dinfuehr.github.io/blog/encoding-of-immediate-values-on-aarch64/ for the details of which immediates are supported.
+This patch is a minimal fix, ideally we should refactor all of the code dealing with immediates in risc.rb, but considering that I don't know ruby and this code is poorly/not tested, I went for the simplest possible fix.
+
+* offlineasm/arm64.rb:
+* offlineasm/mips.rb:
+* offlineasm/risc.rb:
+
2019-11-02 Devin Rousso
Web Inspector: Add diagnostic logging for frontend feature usage
Modified: trunk/Source/_javascript_Core/offlineasm/arm.rb (251965 => 251966)
--- trunk/Source/_javascript_Core/offlineasm/arm.rb 2019-11-02 18:48:15 UTC (rev 251965)
+++ trunk/Source/_javascript_Core/offlineasm/arm.rb 2019-11-02 20:12:38 UTC (rev 251966)
@@ -300,7 +300,7 @@
}
result = riscLowerMalformedAddressesDouble(result)
result = riscLowerMisplacedImmediates(result, ["storeb", "storei", "storep", "storeq"])
-result = riscLowerMalformedImmediates(result, 0..0xff)
+result = riscLowerMalformedImmediates(result, 0..0xff, 0..0x0ff)
result = riscLowerMisplacedAddresses(result)
result = riscLowerRegisterReuse(result)
result = assignRegistersToTemporaries(result, :gpr, ARM_EXTRA_GPRS)
Modified: trunk/Source/_javascript_Core/offlineasm/arm64.rb (251965 => 251966)
--- trunk/Source/_javascript_Core/offlineasm/arm64.rb 2019-11-02 18:48:15 UTC (rev 251965)
+++ trunk/Source/_javascript_Core/offlineasm/arm64.rb 2019-11-02 20:12:38 UTC (rev 251966)
@@ -214,7 +214,6 @@
class Immediate
def arm64Operand(kind)
-raise "Invalid immediate #{value} at #{codeOriginString}" if value < 0 or value > 4095
"\##{value}"
end
end
@@ -418,8 +417,41 @@
false
end
}
+
result = riscLowerMisplacedImmediates(result, ["storeb", "storei", "storep", "storeq"])
-result = riscLowerMalformedImmediates(result, 0..4095)
+
+# The rules for which immediates are valid for and/or/xor instructions are fairly involved, see https://dinfuehr.github.io/blog/encoding-of-immediate-values-on-aarch64/
+validLogicalImmediates = []
+def rotate(value, n, size)
+mask = (1 << size) - 1
+shiftedValue = value << n
+result = (shiftedValue & mask) | ((shiftedValue & ~mask) >> size)
+return result
+end
+def replicate(value, size)
+until size == 64 do
+value = value | (value << size)
+size *= 2
+end
+return value
+end
+size = 2
+until size > 64 do
+for numberOfOnes in 1..(size-1) do
+for rotation in 0..(size-1) do
+immediate = 0;
+for i in 0..(numberOfOnes-1) do
+immediate = immediate*2 + 1
+end
+immediate = rotate(immediate, rotation, size)
+immediate = replicate(immediate, size)
+validLogicalImmediates << immediate
+end
+end
+size *= 2
+end
+result = riscLowerMalformedImmediates(result, 0..4095, validLogicalImmediates)
+
result = riscLowerMisplacedAddresses(result)
result = riscLowerMalformedAddresses(result) {
| node, address |
Modified:
[webkit-changes] [251392] trunk
Title: [251392] trunk
Revision 251392
Author rmoris...@apple.com
Date 2019-10-21 15:47:16 -0700 (Mon, 21 Oct 2019)
Log Message
Throw the right exception upon memory exhaustion in Array::slice
https://bugs.webkit.org/show_bug.cgi?id=202650
Reviewed by Saam Barati.
JSTests:
* stress/array-slice-memory-exhaustion.js: Added.
(foo):
Source/_javascript_Core:
Trivial change: just use tryCreate instead of create, and throw an exception if it fails.
No security implication: we were just crashing instead of throwing a catchable exception.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::slice const):
(JSC::ArrayBuffer::sliceImpl const):
* runtime/ArrayBuffer.h:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferProtoFuncSlice):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/runtime/ArrayBuffer.cpp
trunk/Source/_javascript_Core/runtime/ArrayBuffer.h
trunk/Source/_javascript_Core/runtime/JSArrayBufferPrototype.cpp
trunk/Source/WebCore/platform/mock/mediasource/MockBox.cpp
Diff
Modified: trunk/JSTests/ChangeLog (251391 => 251392)
--- trunk/JSTests/ChangeLog 2019-10-21 22:33:47 UTC (rev 251391)
+++ trunk/JSTests/ChangeLog 2019-10-21 22:47:16 UTC (rev 251392)
@@ -1,5 +1,15 @@
2019-10-21 Robin Morisset
+Throw the right exception upon memory exhaustion in Array::slice
+https://bugs.webkit.org/show_bug.cgi?id=202650
+
+Reviewed by Saam Barati.
+
+* stress/array-slice-memory-exhaustion.js: Added.
+(foo):
+
+2019-10-21 Robin Morisset
+
Post increment/decrement should only call ToNumber once
https://bugs.webkit.org/show_bug.cgi?id=202711
Modified: trunk/Source/_javascript_Core/ChangeLog (251391 => 251392)
--- trunk/Source/_javascript_Core/ChangeLog 2019-10-21 22:33:47 UTC (rev 251391)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-10-21 22:47:16 UTC (rev 251392)
@@ -1,3 +1,20 @@
+2019-10-21 Robin Morisset
+
+Throw the right exception upon memory exhaustion in Array::slice
+https://bugs.webkit.org/show_bug.cgi?id=202650
+
+Reviewed by Saam Barati.
+
+Trivial change: just use tryCreate instead of create, and throw an exception if it fails.
+No security implication: we were just crashing instead of throwing a catchable exception.
+
+* runtime/ArrayBuffer.cpp:
+(JSC::ArrayBuffer::slice const):
+(JSC::ArrayBuffer::sliceImpl const):
+* runtime/ArrayBuffer.h:
+* runtime/JSArrayBufferPrototype.cpp:
+(JSC::arrayBufferProtoFuncSlice):
+
2019-10-21 Basuke Suzuki
[WinCairo][PlayStation] Add automation support for RemoteInspector SocketServer implementation.
Modified: trunk/Source/_javascript_Core/runtime/ArrayBuffer.cpp (251391 => 251392)
--- trunk/Source/_javascript_Core/runtime/ArrayBuffer.cpp 2019-10-21 22:33:47 UTC (rev 251391)
+++ trunk/Source/_javascript_Core/runtime/ArrayBuffer.cpp 2019-10-21 22:47:16 UTC (rev 251392)
@@ -295,21 +295,22 @@
return clampValue(index, 0, currentLength);
}
-Ref ArrayBuffer::slice(double begin, double end) const
+RefPtr ArrayBuffer::slice(double begin, double end) const
{
return sliceImpl(clampIndex(begin), clampIndex(end));
}
-Ref ArrayBuffer::slice(double begin) const
+RefPtr ArrayBuffer::slice(double begin) const
{
return sliceImpl(clampIndex(begin), byteLength());
}
-Ref ArrayBuffer::sliceImpl(unsigned begin, unsigned end) const
+RefPtr ArrayBuffer::sliceImpl(unsigned begin, unsigned end) const
{
unsigned size = begin <= end ? end - begin : 0;
-auto result = ArrayBuffer::create(static_cast(data()) + begin, size);
-result->setSharingMode(sharingMode());
+auto result = ArrayBuffer::tryCreate(static_cast(data()) + begin, size);
+if (result)
+result->setSharingMode(sharingMode());
return result;
}
Modified: trunk/Source/_javascript_Core/runtime/ArrayBuffer.h (251391 => 251392)
--- trunk/Source/_javascript_Core/runtime/ArrayBuffer.h 2019-10-21 22:33:47 UTC (rev 251391)
+++ trunk/Source/_javascript_Core/runtime/ArrayBuffer.h 2019-10-21 22:47:16 UTC (rev 251392)
@@ -132,8 +132,8 @@
inline size_t gcSizeEstimateInBytes() const;
-JS_EXPORT_PRIVATE Ref slice(double begin, double end) const;
-JS_EXPORT_PRIVATE Ref slice(double begin) const;
+JS_EXPORT_PRIVATE RefPtr slice(double begin, double end) const;
+JS_EXPORT_PRIVATE RefPtr slice(double begin) const;
inline void pin();
inline void unpin();
@@ -158,7 +158,7 @@
static Ref createInternal(ArrayBufferContents&&, const void*, unsigned);
static RefPtr tryCreate(unsigned numElements, unsigned elementByteSize, ArrayBufferContents::InitializationPolicy);
ArrayBuffer(ArrayBufferContents&&);
-Ref sliceImpl(unsigned begin, unsigned end) const;
+RefPtr sliceImpl(unsigned begin, unsigned end) const;
inline unsigned clampIndex(double index) const;
static inline
[webkit-changes] [251371] trunk
Title: [251371] trunk
Revision 251371
Author rmoris...@apple.com
Date 2019-10-21 12:06:48 -0700 (Mon, 21 Oct 2019)
Log Message
Post increment/decrement should only call ToNumber once
https://bugs.webkit.org/show_bug.cgi?id=202711
Reviewed by Saam Barati.
JSTests:
* stress/postinc-custom-valueOf.js: Added.
(postInc):
(postDec):
Source/_javascript_Core:
The problem is that we first called ToNumber on the object being incremented (to have the result that we'll eventually return), but we then do emitIncOrDec on the original object, which can call ToNumber again.
Instead we must do the ToNumber once, then copy its result, emitIncOrDec on the copy, put the copy back in the original location, and finally return the old value.
Since the result of ToNumber is guaranteed not to be an object, emitIncOrDec won't call ToNumber a second time.
* bytecompiler/NodesCodegen.cpp:
(JSC::emitPostIncOrDec):
Modified Paths
trunk/JSTests/ChangeLog
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp
Added Paths
trunk/JSTests/stress/postinc-custom-valueOf.js
Diff
Modified: trunk/JSTests/ChangeLog (251370 => 251371)
--- trunk/JSTests/ChangeLog 2019-10-21 18:59:22 UTC (rev 251370)
+++ trunk/JSTests/ChangeLog 2019-10-21 19:06:48 UTC (rev 251371)
@@ -1,3 +1,14 @@
+2019-10-21 Robin Morisset
+
+Post increment/decrement should only call ToNumber once
+https://bugs.webkit.org/show_bug.cgi?id=202711
+
+Reviewed by Saam Barati.
+
+* stress/postinc-custom-valueOf.js: Added.
+(postInc):
+(postDec):
+
2019-10-18 Yusuke Suzuki
[JSC] DFG::CommonData modification by DFG reallyAdd should be guarded by CodeBlock's lock
Added: trunk/JSTests/stress/postinc-custom-valueOf.js (0 => 251371)
--- trunk/JSTests/stress/postinc-custom-valueOf.js (rev 0)
+++ trunk/JSTests/stress/postinc-custom-valueOf.js 2019-10-21 19:06:48 UTC (rev 251371)
@@ -0,0 +1,22 @@
+function postInc() {
+var counter = 0;
+var o = {};
+o.valueOf = () => {counter++; return 42};
+var x = o++; // The "var x =" part is required, or this gets transformed into ++o super early
+if (counter != 1)
+throw "A post-increment called valueOf " + counter + " times instead of just once.";
+}
+
+function postDec() {
+var counter = 0;
+var o = {};
+o.valueOf = () => {counter++; return 42};
+var x = o--; // The "var x =" part is required, or this gets transformed into --o super early
+if (counter != 1)
+throw "A pre-increment called valueOf " + counter + " times instead of just once.";
+}
+
+for (var i = 0; i < 2; ++i) {
+postInc();
+postDec();
+}
Modified: trunk/Source/_javascript_Core/ChangeLog (251370 => 251371)
--- trunk/Source/_javascript_Core/ChangeLog 2019-10-21 18:59:22 UTC (rev 251370)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-10-21 19:06:48 UTC (rev 251371)
@@ -1,3 +1,17 @@
+2019-10-21 Robin Morisset
+
+Post increment/decrement should only call ToNumber once
+https://bugs.webkit.org/show_bug.cgi?id=202711
+
+Reviewed by Saam Barati.
+
+The problem is that we first called ToNumber on the object being incremented (to have the result that we'll eventually return), but we then do emitIncOrDec on the original object, which can call ToNumber again.
+Instead we must do the ToNumber once, then copy its result, emitIncOrDec on the copy, put the copy back in the original location, and finally return the old value.
+Since the result of ToNumber is guaranteed not to be an object, emitIncOrDec won't call ToNumber a second time.
+
+* bytecompiler/NodesCodegen.cpp:
+(JSC::emitPostIncOrDec):
+
2019-10-18 Yusuke Suzuki
[JSC] DFG::CommonData modification by DFG reallyAdd should be guarded by CodeBlock's lock
Modified: trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp (251370 => 251371)
--- trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp 2019-10-21 18:59:22 UTC (rev 251370)
+++ trunk/Source/_javascript_Core/bytecompiler/NodesCodegen.cpp 2019-10-21 19:06:48 UTC (rev 251371)
@@ -1784,8 +1784,11 @@
{
if (dst == srcDst)
return generator.emitToNumber(generator.finalDestination(dst), srcDst);
-RefPtr tmp = generator.emitToNumber(generator.tempDestination(dst), srcDst);
-emitIncOrDec(generator, srcDst, oper);
+RefPtr tmp = generator.emitToNumber(generator.newTemporary(), srcDst);
+RefPtr result = generator.tempDestination(srcDst);
+generator.move(result.get(), tmp.get());
+emitIncOrDec(generator, result.get(), oper);
+generator.move(srcDst, result.get());
return generator.move(dst, tmp.get());
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [250867] trunk/Source/WTF
Title: [250867] trunk/Source/WTF
Revision 250867
Author rmoris...@apple.com
Date 2019-10-08 15:16:04 -0700 (Tue, 08 Oct 2019)
Log Message
dataLogIf should be ALWAYS_INLINE
https://bugs.webkit.org/show_bug.cgi?id=202703
Reviewed by Saam Barati.
We often have the following pattern:
```
static constexpr bool verbose = false;
...
dataLogLnIf(verbose, "Something is happening");
```
To make sure that these are always properly eliminated I'd like to make dataLogIf/dataLogLnIf ALWAYS_INLINE.
We may as well mark the branch as UNLIKELY too, for the cases where the condition comes from Options::verboseSomething() and is only known at runtime.
* wtf/DataLog.h:
(WTF::dataLogIf):
(WTF::dataLogLnIf):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/DataLog.h
Diff
Modified: trunk/Source/WTF/ChangeLog (250866 => 250867)
--- trunk/Source/WTF/ChangeLog 2019-10-08 22:13:39 UTC (rev 250866)
+++ trunk/Source/WTF/ChangeLog 2019-10-08 22:16:04 UTC (rev 250867)
@@ -1,3 +1,24 @@
+2019-10-08 Robin Morisset
+
+dataLogIf should be ALWAYS_INLINE
+https://bugs.webkit.org/show_bug.cgi?id=202703
+
+Reviewed by Saam Barati.
+
+We often have the following pattern:
+```
+static constexpr bool verbose = false;
+...
+dataLogLnIf(verbose, "Something is happening");
+```
+To make sure that these are always properly eliminated I'd like to make dataLogIf/dataLogLnIf ALWAYS_INLINE.
+
+We may as well mark the branch as UNLIKELY too, for the cases where the condition comes from Options::verboseSomething() and is only known at runtime.
+
+* wtf/DataLog.h:
+(WTF::dataLogIf):
+(WTF::dataLogLnIf):
+
2019-10-07 Alexey Proskuryakov
Build failure in WebHTMLView.mm with the public SDK (Xcode 11 and Mojave)
Modified: trunk/Source/WTF/wtf/DataLog.h (250866 => 250867)
--- trunk/Source/WTF/wtf/DataLog.h 2019-10-08 22:13:39 UTC (rev 250866)
+++ trunk/Source/WTF/wtf/DataLog.h 2019-10-08 22:16:04 UTC (rev 250867)
@@ -52,16 +52,16 @@
}
template
-void dataLogIf(bool shouldLog, const Types&... values)
+ALWAYS_INLINE void dataLogIf(bool shouldLog, const Types&... values)
{
-if (shouldLog)
+if (UNLIKELY(shouldLog))
dataLog(values...);
}
template
-void dataLogLnIf(bool shouldLog, const Types&... values)
+ALWAYS_INLINE void dataLogLnIf(bool shouldLog, const Types&... values)
{
-if (shouldLog)
+if (UNLIKELY(shouldLog))
dataLogLn(values...);
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [249677] trunk/Source/JavaScriptCore
Title: [249677] trunk/Source/_javascript_Core
Revision 249677
Author rmoris...@apple.com
Date 2019-09-09 17:23:50 -0700 (Mon, 09 Sep 2019)
Log Message
[Air] highOrderAdjacents in AbstractColoringAllocator::conservativeHeuristic should be some kind of array
https://bugs.webkit.org/show_bug.cgi?id=197305
Reviewed by Keith Miller.
Currently it is a HashSet, but it only ever holds at most registerCount() items. And linear search tends to be faster on such a small collection than hashing + searching in a HashSet.
Further benefits include avoiding the allocation of the HashSet, not actually adding the nodes adjacent to V (since there are no duplicates in the adjacency lists).
This patch also contains a trivial optimization: if the remaining number of nodes to consider + the number of highOrderAdjacents already seen is smaller than registerCount() we can return true directly.
Apart from that, the patch got some trivial cleanup of GraphColoringRegisterAllocation::allocateOnBank() (that for example was only logging the number of iterations for FP registers, and not the more interesting number for GP registers).
The time spent in the register allocator throughout JetStream2 on this MacBook Pro moves from 3767 / 3710 / 3785 ms to 3551 / 3454 / 3503 ms.
So about a 6% speedup for that phase, and between 1 and 1.5% speedup for FTL/OMG compilation overall.
No new tests as there is no intended change to the code being generated, and this was already tested by running testb3 + JetStream2.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (249676 => 249677)
--- trunk/Source/_javascript_Core/ChangeLog 2019-09-09 23:51:16 UTC (rev 249676)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-09-10 00:23:50 UTC (rev 249677)
@@ -1,3 +1,23 @@
+2019-09-09 Robin Morisset
+
+[Air] highOrderAdjacents in AbstractColoringAllocator::conservativeHeuristic should be some kind of array
+https://bugs.webkit.org/show_bug.cgi?id=197305
+
+Reviewed by Keith Miller.
+
+Currently it is a HashSet, but it only ever holds at most registerCount() items. And linear search tends to be faster on such a small collection than hashing + searching in a HashSet.
+Further benefits include avoiding the allocation of the HashSet, not actually adding the nodes adjacent to V (since there are no duplicates in the adjacency lists).
+
+This patch also contains a trivial optimization: if the remaining number of nodes to consider + the number of highOrderAdjacents already seen is smaller than registerCount() we can return true directly.
+Apart from that, the patch got some trivial cleanup of GraphColoringRegisterAllocation::allocateOnBank() (that for example was only logging the number of iterations for FP registers, and not the more interesting number for GP registers).
+
+The time spent in the register allocator throughout JetStream2 on this MacBook Pro moves from 3767 / 3710 / 3785 ms to 3551 / 3454 / 3503 ms.
+So about a 6% speedup for that phase, and between 1 and 1.5% speedup for FTL/OMG compilation overall.
+
+No new tests as there is no intended change to the code being generated, and this was already tested by running testb3 + JetStream2.
+
+* b3/air/AirAllocateRegistersByGraphColoring.cpp:
+
2019-09-09 Yusuke Suzuki
[JSC] Use metadata table to iterate specific bytecode metadata instead of propertyAccessInstructions vector
Modified: trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp (249676 => 249677)
--- trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2019-09-09 23:51:16 UTC (rev 249676)
+++ trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2019-09-10 00:23:50 UTC (rev 249677)
@@ -192,32 +192,45 @@
const auto& adjacentsOfU = m_adjacencyList[u];
const auto& adjacentsOfV = m_adjacencyList[v];
-if (adjacentsOfU.size() + adjacentsOfV.size() < registerCount()) {
+Vector highOrderAdjacents;
+RELEASE_ASSERT(registerCount() <= MacroAssembler::numGPRs + MacroAssembler::numFPRs);
+unsigned numCandidates = adjacentsOfU.size() + adjacentsOfV.size();
+if (numCandidates < registerCount()) {
// Shortcut: if the total number of adjacents is less than the number of register, the condition is always met.
return true;
}
-HashSet highOrderAdjacents;
-
for (IndexType adjacentTmpIndex : adjacentsOfU) {
ASSERT(adjacentTmpIndex != v);
ASSERT(adjacentTmpIndex != u);
+numCandidates--;
if (!hasBeenSimplified(adjacentTmpIndex) && m_degrees[adjacentTmpIndex] >= registerCount()) {
-auto addResult =
[webkit-changes] [248746] trunk
Title: [248746] trunk
Revision 248746
Author rmoris...@apple.com
Date 2019-08-15 14:18:11 -0700 (Thu, 15 Aug 2019)
Log Message
[WHLSL] Don't accept operator&& or operator|| in the Lexer
https://bugs.webkit.org/show_bug.cgi?id=200785
Reviewed by Saam Barati.
Source/WebCore:
Implementing && or || as function calls would lose us short-circuiting.
2 new tests in LayoutTests/webgpu/whlsl/lexing.html
* Modules/webgpu/WHLSL/WHLSLLexer.cpp:
(WebCore::WHLSL::Lexer::consumeTokenFromStream):
LayoutTests:
* webgpu/whlsl/lexing.html:
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/webgpu/whlsl/lexing.html
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp
Diff
Modified: trunk/LayoutTests/ChangeLog (248745 => 248746)
--- trunk/LayoutTests/ChangeLog 2019-08-15 20:50:02 UTC (rev 248745)
+++ trunk/LayoutTests/ChangeLog 2019-08-15 21:18:11 UTC (rev 248746)
@@ -1,3 +1,12 @@
+2019-08-15 Robin Morisset
+
+[WHLSL] Don't accept operator&& or operator|| in the Lexer
+https://bugs.webkit.org/show_bug.cgi?id=200785
+
+Reviewed by Saam Barati.
+
+* webgpu/whlsl/lexing.html:
+
2019-08-15 Devin Rousso
Web Inspector: support `console.screenshot` with detached
Modified: trunk/LayoutTests/webgpu/whlsl/lexing.html (248745 => 248746)
--- trunk/LayoutTests/webgpu/whlsl/lexing.html 2019-08-15 20:50:02 UTC (rev 248745)
+++ trunk/LayoutTests/webgpu/whlsl/lexing.html 2019-08-15 21:18:11 UTC (rev 248746)
@@ -155,6 +155,18 @@
return 42;
}
`);
+
+await checkFail(`
+int operator&&(int x, int y) {
+return 42;
+}
+`);
+
+await checkFail(`
+bool operator||(int x, int y) {
+return 42;
+}
+`);
};
runTests(whlslTests);
Modified: trunk/Source/WebCore/ChangeLog (248745 => 248746)
--- trunk/Source/WebCore/ChangeLog 2019-08-15 20:50:02 UTC (rev 248745)
+++ trunk/Source/WebCore/ChangeLog 2019-08-15 21:18:11 UTC (rev 248746)
@@ -1,3 +1,17 @@
+2019-08-15 Robin Morisset
+
+[WHLSL] Don't accept operator&& or operator|| in the Lexer
+https://bugs.webkit.org/show_bug.cgi?id=200785
+
+Reviewed by Saam Barati.
+
+Implementing && or || as function calls would lose us short-circuiting.
+
+2 new tests in LayoutTests/webgpu/whlsl/lexing.html
+
+* Modules/webgpu/WHLSL/WHLSLLexer.cpp:
+(WebCore::WHLSL::Lexer::consumeTokenFromStream):
+
2019-08-15 Saam Barati
Unreviewed. Debug build fix after r248730.
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp (248745 => 248746)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp 2019-08-15 20:50:02 UTC (rev 248745)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp 2019-08-15 21:18:11 UTC (rev 248746)
@@ -868,9 +868,6 @@
if (consume(']'))
return token(Token::Type::OperatorName);
return token(Token::Type::Invalid);
-case '&':
-shift();
-return token(Token::Type::OperatorName);
case '.':
shift();
if (!isValidIdentifierStart(peek()))
@@ -918,7 +915,6 @@
case '|':
shift();
-consume('|');
return token(Token::Type::OperatorName);
case '=':
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [248729] trunk/Source/WebCore
Title: [248729] trunk/Source/WebCore
Revision 248729
Author rmoris...@apple.com
Date 2019-08-15 10:49:38 -0700 (Thu, 15 Aug 2019)
Log Message
[WHLSL] Trivial clean-up of the MSL code generated
https://bugs.webkit.org/show_bug.cgi?id=200525
Reviewed by Darin Adler.
Emit simpler code for ternary expressions
Remove duplicate {} around functions
No new tests as it is covered by the existing ones.
* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::visit):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (248728 => 248729)
--- trunk/Source/WebCore/ChangeLog 2019-08-15 17:44:07 UTC (rev 248728)
+++ trunk/Source/WebCore/ChangeLog 2019-08-15 17:49:38 UTC (rev 248729)
@@ -1,3 +1,18 @@
+2019-08-15 Robin Morisset
+
+[WHLSL] Trivial clean-up of the MSL code generated
+https://bugs.webkit.org/show_bug.cgi?id=200525
+
+Reviewed by Darin Adler.
+
+Emit simpler code for ternary expressions
+Remove duplicate {} around functions
+
+No new tests as it is covered by the existing ones.
+
+* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
+(WebCore::WHLSL::Metal::FunctionDefinitionWriter::visit):
+
2019-08-15 Youenn Fablet
Always create a Document with a valid SessionID
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp (248728 => 248729)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp 2019-08-15 17:44:07 UTC (rev 248728)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp 2019-08-15 17:49:38 UTC (rev 248729)
@@ -247,10 +247,10 @@
ASSERT_UNUSED(addResult, addResult.isNewEntry);
m_stringBuilder.flexibleAppend(m_typeNamer.mangledNameForType(*parameter->type()), ' ', parameterName);
}
-m_stringBuilder.append(") {\n");
+m_stringBuilder.append(")\n");
checkErrorAndVisit(functionDefinition.block());
ASSERT(m_stack.isEmpty());
-m_stringBuilder.append("}\n");
+m_stringBuilder.append('\n');
}
}
@@ -679,22 +679,13 @@
{
checkErrorAndVisit(ternaryExpression.predicate());
auto check = takeLastValue();
+checkErrorAndVisit(ternaryExpression.bodyExpression());
+auto body = takeLastValue();
+checkErrorAndVisit(ternaryExpression.elseExpression());
+auto elseBody = takeLastValue();
auto variableName = generateNextVariableName();
-m_stringBuilder.flexibleAppend(
-m_typeNamer.mangledNameForType(ternaryExpression.resolvedType()), ' ', variableName, ";\n"
-"if (", check, ") {\n"
-);
-checkErrorAndVisit(ternaryExpression.bodyExpression());
-m_stringBuilder.flexibleAppend(
-variableName, " = ", takeLastValue(), ";\n"
-"} else {\n"
-);
-checkErrorAndVisit(ternaryExpression.elseExpression());
-m_stringBuilder.flexibleAppend(
-variableName, " = ", takeLastValue(), ";\n"
-"}\n"
-);
+m_stringBuilder.flexibleAppend(m_typeNamer.mangledNameForType(ternaryExpression.resolvedType()), ' ', variableName, " = ", check, " ? ", body, " : ", elseBody, ";\n");
appendRightValue(ternaryExpression, variableName);
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [248656] trunk/Source/WebCore
Title: [248656] trunk/Source/WebCore
Revision 248656
Author rmoris...@apple.com
Date 2019-08-13 18:36:26 -0700 (Tue, 13 Aug 2019)
Log Message
[WHLSL] Move Qualifiers and Semantic from VariableDeclaration to VariableDeclaration::RareData
https://bugs.webkit.org/show_bug.cgi?id=200696
Reviewed by Myles C. Maxfield.
Shrinking VariableDeclaration by 16 bytes in the common case.
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (248655 => 248656)
--- trunk/Source/WebCore/ChangeLog 2019-08-14 01:19:31 UTC (rev 248655)
+++ trunk/Source/WebCore/ChangeLog 2019-08-14 01:36:26 UTC (rev 248656)
@@ -1,5 +1,18 @@
2019-08-13 Robin Morisset
+[WHLSL] Move Qualifiers and Semantic from VariableDeclaration to VariableDeclaration::RareData
+https://bugs.webkit.org/show_bug.cgi?id=200696
+
+Reviewed by Myles C. Maxfield.
+
+Shrinking VariableDeclaration by 16 bytes in the common case.
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h:
+
+2019-08-13 Robin Morisset
+
[WHLSL] Don't generate empty comma expressions for bare ';'
https://bugs.webkit.org/show_bug.cgi?id=200681
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h (248655 => 248656)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h 2019-08-14 01:19:31 UTC (rev 248655)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h 2019-08-14 01:36:26 UTC (rev 248656)
@@ -47,14 +47,24 @@
WTF_MAKE_FAST_ALLOCATED;
// Final because we made the destructor non-virtual.
public:
+struct RareData {
+RareData(Qualifiers&& qualifiersArgument, std::unique_ptr&& semanticArgument)
+: qualifiers(WTFMove(qualifiersArgument))
+, semantic(WTFMove(semanticArgument))
+{
+}
+Qualifiers qualifiers;
+std::unique_ptr semantic;
+};
+
VariableDeclaration(CodeLocation codeLocation, Qualifiers&& qualifiers, RefPtr type, String&& name, std::unique_ptr&& semantic, std::unique_ptr<_expression_>&& initializer)
: m_codeLocation(codeLocation)
-, m_qualifiers(WTFMove(qualifiers))
, m_type(WTFMove(type))
+, m_initializer(WTFMove(initializer))
, m_name(WTFMove(name))
-, m_semantic(WTFMove(semantic))
-, m_initializer(WTFMove(initializer))
{
+if (semantic || !qualifiers.isEmpty())
+m_rareData = std::make_unique(WTFMove(qualifiers), WTFMove(semantic));
}
~VariableDeclaration() = default;
@@ -74,7 +84,6 @@
}
const RefPtr& type() const { return m_type; }
UnnamedType* type() { return m_type ? &*m_type : nullptr; }
-Semantic* semantic() { return m_semantic.get(); }
_expression_* initializer() { return m_initializer.get(); }
bool isAnonymous() const { return m_name.isNull(); }
std::unique_ptr<_expression_> takeInitializer() { return WTFMove(m_initializer); }
@@ -86,13 +95,14 @@
}
CodeLocation codeLocation() const { return m_codeLocation; }
+Semantic* semantic() { return m_rareData ? m_rareData->semantic.get() : nullptr; }
+
private:
CodeLocation m_codeLocation;
-Qualifiers m_qualifiers;
RefPtr m_type;
+std::unique_ptr<_expression_> m_initializer;
+std::unique_ptr m_rareData { nullptr };
String m_name;
-std::unique_ptr m_semantic;
-std::unique_ptr<_expression_> m_initializer;
};
using VariableDeclarations = Vector>;
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [248650] trunk/Source/WebCore
Title: [248650] trunk/Source/WebCore
Revision 248650
Author rmoris...@apple.com
Date 2019-08-13 18:05:27 -0700 (Tue, 13 Aug 2019)
Log Message
[WHLSL] Don't generate empty comma expressions for bare ';'
https://bugs.webkit.org/show_bug.cgi?id=200681
Reviewed by Myles C. Maxfield.
Currently we emit a comma _expression_ with no sub-_expression_ for bare ';', as well as for the initialization of for loops with no initializers.
This crashes the Checker, as it tries to access the last sub-_expression_ of comma expressions.
Instead we should generate an empty statement block for that case.
This problem was found (and originally fixed before the commit was reverted) in https://bugs.webkit.org/show_bug.cgi?id=199726.
I am just isolating the fix here for easier review and debugging.
New test: LayoutTests/webgpu/whlsl/for-loop.html
* Modules/webgpu/WHLSL/AST/WHLSLForLoop.h:
* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::visit):
* Modules/webgpu/WHLSL/WHLSLASTDumper.cpp:
(WebCore::WHLSL::ASTDumper::visit):
* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
(WebCore::WHLSL::Checker::visit):
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseForLoop):
(WebCore::WHLSL::Parser::parseStatement):
(WebCore::WHLSL::Parser::parseEffectfulExpression):
* Modules/webgpu/WHLSL/WHLSLParser.h:
* Modules/webgpu/WHLSL/WHLSLVisitor.cpp:
(WebCore::WHLSL::Visitor::visit):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLASTDumper.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLVisitor.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (248649 => 248650)
--- trunk/Source/WebCore/ChangeLog 2019-08-14 01:03:08 UTC (rev 248649)
+++ trunk/Source/WebCore/ChangeLog 2019-08-14 01:05:27 UTC (rev 248650)
@@ -1,3 +1,34 @@
+2019-08-13 Robin Morisset
+
+[WHLSL] Don't generate empty comma expressions for bare ';'
+https://bugs.webkit.org/show_bug.cgi?id=200681
+
+Reviewed by Myles C. Maxfield.
+
+Currently we emit a comma _expression_ with no sub-_expression_ for bare ';', as well as for the initialization of for loops with no initializers.
+This crashes the Checker, as it tries to access the last sub-_expression_ of comma expressions.
+Instead we should generate an empty statement block for that case.
+
+This problem was found (and originally fixed before the commit was reverted) in https://bugs.webkit.org/show_bug.cgi?id=199726.
+I am just isolating the fix here for easier review and debugging.
+
+New test: LayoutTests/webgpu/whlsl/for-loop.html
+
+* Modules/webgpu/WHLSL/AST/WHLSLForLoop.h:
+* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
+(WebCore::WHLSL::Metal::FunctionDefinitionWriter::visit):
+* Modules/webgpu/WHLSL/WHLSLASTDumper.cpp:
+(WebCore::WHLSL::ASTDumper::visit):
+* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
+(WebCore::WHLSL::Checker::visit):
+* Modules/webgpu/WHLSL/WHLSLParser.cpp:
+(WebCore::WHLSL::Parser::parseForLoop):
+(WebCore::WHLSL::Parser::parseStatement):
+(WebCore::WHLSL::Parser::parseEffectfulExpression):
+* Modules/webgpu/WHLSL/WHLSLParser.h:
+* Modules/webgpu/WHLSL/WHLSLVisitor.cpp:
+(WebCore::WHLSL::Visitor::visit):
+
2019-08-13 Daniel Bates
Focus rings are black
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h (248649 => 248650)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h 2019-08-14 01:03:08 UTC (rev 248649)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h 2019-08-14 01:05:27 UTC (rev 248650)
@@ -45,7 +45,7 @@
class ForLoop final : public Statement {
WTF_MAKE_FAST_ALLOCATED;
public:
-ForLoop(CodeLocation location, Variant, UniqueRef<_expression_>>&& initialization, std::unique_ptr<_expression_>&& condition, std::unique_ptr<_expression_>&& increment, UniqueRef&& body)
+ForLoop(CodeLocation location, UniqueRef&& initialization, std::unique_ptr<_expression_>&& condition, std::unique_ptr<_expression_>&& increment, UniqueRef&& body)
: Statement(location, Kind::ForLoop)
, m_initialization(WTFMove(initialization))
, m_condition(WTFMove(condition))
@@ -59,13 +59,13 @@
ForLoop(const ForLoop&) = delete;
ForLoop(ForLoop&&) = default;
-Variant, UniqueRef<_expression_>>& initialization() { return m_initialization; }
+UniqueRef& initialization() { return m_initialization; }
_expression_* condition() { return m_condition.get(); }
_expression_* increment() { return
[webkit-changes] [248384] trunk/Source/WebCore
Title: [248384] trunk/Source/WebCore
Revision 248384
Author rmoris...@apple.com
Date 2019-08-07 12:58:15 -0700 (Wed, 07 Aug 2019)
Log Message
[WHLSL] Simplify and eliminate redundant work in WHLSLFunctionWriter.cpp
https://bugs.webkit.org/show_bug.cgi?id=200460
Reviewed by Myles Maxfield.
2 trivial simplifications:
- Replace FunctionDeclarationWriter by a standalone function, there was no reason to make it a subclass of Visitor
- Avoid an exponential blow-up in the computation of reachable functions.
I have way too much noise on my system (swings back and forth between 7 and 12ms for this phase) to measure a performance win,
but since this patch simplifies things without adding complexity I think it is worth it.
No new test as there is no functional change intended.
* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
(WebCore::WHLSL::Metal::declareFunction):
(WebCore::WHLSL::Metal::FunctionDefinitionWriter::FunctionDefinitionWriter):
(WebCore::WHLSL::Metal::RenderFunctionDefinitionWriter::RenderFunctionDefinitionWriter):
(WebCore::WHLSL::Metal::ComputeFunctionDefinitionWriter::ComputeFunctionDefinitionWriter):
(WebCore::WHLSL::Metal::sharedMetalFunctions):
(WebCore::WHLSL::Metal::metalFunctions):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (248383 => 248384)
--- trunk/Source/WebCore/ChangeLog 2019-08-07 19:50:04 UTC (rev 248383)
+++ trunk/Source/WebCore/ChangeLog 2019-08-07 19:58:15 UTC (rev 248384)
@@ -1,3 +1,27 @@
+2019-08-07 Robin Morisset
+
+[WHLSL] Simplify and eliminate redundant work in WHLSLFunctionWriter.cpp
+https://bugs.webkit.org/show_bug.cgi?id=200460
+
+Reviewed by Myles Maxfield.
+
+2 trivial simplifications:
+- Replace FunctionDeclarationWriter by a standalone function, there was no reason to make it a subclass of Visitor
+- Avoid an exponential blow-up in the computation of reachable functions.
+
+I have way too much noise on my system (swings back and forth between 7 and 12ms for this phase) to measure a performance win,
+but since this patch simplifies things without adding complexity I think it is worth it.
+
+No new test as there is no functional change intended.
+
+* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
+(WebCore::WHLSL::Metal::declareFunction):
+(WebCore::WHLSL::Metal::FunctionDefinitionWriter::FunctionDefinitionWriter):
+(WebCore::WHLSL::Metal::RenderFunctionDefinitionWriter::RenderFunctionDefinitionWriter):
+(WebCore::WHLSL::Metal::ComputeFunctionDefinitionWriter::ComputeFunctionDefinitionWriter):
+(WebCore::WHLSL::Metal::sharedMetalFunctions):
+(WebCore::WHLSL::Metal::metalFunctions):
+
2019-08-07 Saam Barati
[WHLSL] checkRecursion, checkTextureReferences, and EscapedVariableCollector should skip stdlib functions
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp (248383 => 248384)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp 2019-08-07 19:50:04 UTC (rev 248383)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp 2019-08-07 19:58:15 UTC (rev 248384)
@@ -47,39 +47,20 @@
namespace Metal {
-class FunctionDeclarationWriter final : public Visitor {
-public:
-FunctionDeclarationWriter(StringBuilder& stringBuilder, TypeNamer& typeNamer, HashMap& functionMapping)
-: m_typeNamer(typeNamer)
-, m_functionMapping(functionMapping)
-, m_stringBuilder(stringBuilder)
-{
-}
-
-virtual ~FunctionDeclarationWriter() = default;
-
-void visit(AST::FunctionDeclaration&) override;
-
-private:
-TypeNamer& m_typeNamer;
-HashMap& m_functionMapping;
-StringBuilder& m_stringBuilder;
-};
-
-void FunctionDeclarationWriter::visit(AST::FunctionDeclaration& functionDeclaration)
+static void declareFunction(StringBuilder& stringBuilder, AST::FunctionDeclaration& functionDeclaration, TypeNamer& typeNamer, HashMap& functionMapping)
{
if (functionDeclaration.entryPointType())
return;
-auto iterator = m_functionMapping.find();
-ASSERT(iterator != m_functionMapping.end());
-m_stringBuilder.flexibleAppend(m_typeNamer.mangledNameForType(functionDeclaration.type()), ' ', iterator->value, '(');
+auto iterator = functionMapping.find();
+ASSERT(iterator != functionMapping.end());
+stringBuilder.flexibleAppend(typeNamer.mangledNameForType(functionDeclaration.type()), ' ', iterator->value, '(');
for (size_t i = 0; i < functionDeclaration.parameters().size(); ++i) {
if (i)
-m_stringBuilder.append(", ");
-m_stringBuilder.flexibleAppend(m_typeNamer.mangledNameForType(*functionDeclaration.parameters()[i]->type()));
+stringBuilder.append(", ");
+
[webkit-changes] [248194] trunk/Source/WebCore
Title: [248194] trunk/Source/WebCore
Revision 248194
Author rmoris...@apple.com
Date 2019-08-02 18:10:43 -0700 (Fri, 02 Aug 2019)
Log Message
[WHLSL] Avoid visiting the full AST in computeDimensions
https://bugs.webkit.org/show_bug.cgi?id=200410
Reviewed by Myles C. Maxfield.
Avoid visiting the full AST in computeDimensions
This cuts the time spent in computeDimensions on compute_boids.html from about 2ms to about 0.002ms.
No new tests as there is no functional change intended.
* Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp:
(WebCore::WHLSL::computeDimensions):
* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (248193 => 248194)
--- trunk/Source/WebCore/ChangeLog 2019-08-03 00:49:41 UTC (rev 248193)
+++ trunk/Source/WebCore/ChangeLog 2019-08-03 01:10:43 UTC (rev 248194)
@@ -1,3 +1,19 @@
+2019-08-02 Robin Morisset
+
+[WHLSL] Avoid visiting the full AST in computeDimensions
+https://bugs.webkit.org/show_bug.cgi?id=200410
+
+Reviewed by Myles C. Maxfield.
+
+Avoid visiting the full AST in computeDimensions
+This cuts the time spent in computeDimensions on compute_boids.html from about 2ms to about 0.002ms.
+
+No new tests as there is no functional change intended.
+
+* Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp:
+(WebCore::WHLSL::computeDimensions):
+* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
+
2019-08-02 Ryosuke Niwa
Ref Frame in DOMWindow::screen* functions
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp (248193 => 248194)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp 2019-08-03 00:49:41 UTC (rev 248193)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLComputeDimensions.cpp 2019-08-03 01:10:43 UTC (rev 248194)
@@ -38,50 +38,31 @@
namespace WHLSL {
-class ComputeDimensionsVisitor : public Visitor {
-public:
-ComputeDimensionsVisitor(AST::FunctionDefinition& entryPoint)
-: m_entryPoint(entryPoint)
-{
-}
+Optional computeDimensions(Program& program, AST::FunctionDefinition& entryPoint)
+{
+Optional computeDimensions;
-virtual ~ComputeDimensionsVisitor() = default;
-
-Optional computeDimensions() const { return m_computeDimensions; }
-
-private:
-void visit(AST::FunctionDeclaration& functionDeclaration) override
-{
+for (auto& functionDefinition : program.functionDefinitions()) {
bool foundNumThreadsFunctionAttribute = false;
-for (auto& functionAttribute : functionDeclaration.attributeBlock()) {
+for (auto& functionAttribute : functionDefinition->attributeBlock()) {
auto success = WTF::visit(WTF::makeVisitor([&](AST::NumThreadsFunctionAttribute& numThreadsFunctionAttribute) {
if (foundNumThreadsFunctionAttribute)
return false;
foundNumThreadsFunctionAttribute = true;
-if ( == _entryPoint) {
-ASSERT(!m_computeDimensions);
-m_computeDimensions = {{ numThreadsFunctionAttribute.width(), numThreadsFunctionAttribute.height(), numThreadsFunctionAttribute.depth() }};
+if ( == ) {
+ASSERT(!computeDimensions);
+computeDimensions = {{ numThreadsFunctionAttribute.width(), numThreadsFunctionAttribute.height(), numThreadsFunctionAttribute.depth() }};
}
return true;
}), functionAttribute);
if (!success) {
-setError(Error("Cannot declare multiple numthread attributes.", functionDeclaration.codeLocation()));
-return;
+// Cannot declare multiple numthread attributes on a single function.
+return WTF::nullopt;
}
}
}
-AST::FunctionDefinition& m_entryPoint;
-Optional m_computeDimensions;
-};
-
-Optional computeDimensions(Program& program, AST::FunctionDefinition& entryPoint)
-{
-ComputeDimensionsVisitor computeDimensions(entryPoint);
-computeDimensions.Visitor::visit(program);
-if (computeDimensions.hasError())
-return WTF::nullopt;
-return computeDimensions.computeDimensions();
+return computeDimensions;
}
} // namespace WHLSL
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [247554] trunk
Title: [247554] trunk
Revision 247554
Author rmoris...@apple.com
Date 2019-07-17 19:29:54 -0700 (Wed, 17 Jul 2019)
Log Message
[WHLSL] The lexer should not choke on a single '/'
https://bugs.webkit.org/show_bug.cgi?id=199886
Reviewed by Myles Maxfield.
Source/WebCore:
The bug is trivial: just recognize that a single '/' without a '*' or '/' afterwards is not the beginning of a comment.
While investigating this bug, I also found that part of the parser fails to properly propagate errors, so I fixed it.
New test in LayoutTests/webgpu/whlsl/float-math.html
I also added a new flag to WHLSLPrepare.cpp. It can be used to parse the full standard library (this is how I found this bug in the first place).
* Modules/webgpu/WHLSL/WHLSLLexer.cpp:
(WebCore::WHLSL::Lexer::skipWhitespaceAndComments):
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parsePossibleTernaryConditional):
* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
(WebCore::WHLSL::prepareShared):
* Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.cpp:
(WebCore::WHLSL::includeStandardLibrary):
* Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.h:
LayoutTests:
Added a new basic test of division.
* webgpu/whlsl/float-math.html:
Modified Paths
trunk/LayoutTests/ChangeLog
trunk/LayoutTests/webgpu/whlsl/float-math.html
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPrepare.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.h
Diff
Modified: trunk/LayoutTests/ChangeLog (247553 => 247554)
--- trunk/LayoutTests/ChangeLog 2019-07-18 02:00:06 UTC (rev 247553)
+++ trunk/LayoutTests/ChangeLog 2019-07-18 02:29:54 UTC (rev 247554)
@@ -1,3 +1,14 @@
+2019-07-17 Robin Morisset
+
+[WHLSL] The lexer should not choke on a single '/'
+https://bugs.webkit.org/show_bug.cgi?id=199886
+
+Reviewed by Myles Maxfield.
+
+Added a new basic test of division.
+
+* webgpu/whlsl/float-math.html:
+
2019-07-17 Antoine Quint
Unable to bring up custom media controls on iOS for video.sina.cn
Modified: trunk/LayoutTests/webgpu/whlsl/float-math.html (247553 => 247554)
--- trunk/LayoutTests/webgpu/whlsl/float-math.html 2019-07-18 02:00:06 UTC (rev 247553)
+++ trunk/LayoutTests/webgpu/whlsl/float-math.html 2019-07-18 02:29:54 UTC (rev 247554)
@@ -37,6 +37,10 @@
float x = 7.5;
return float(x);
}
+bool div()
+{
+return 0.5 / 2 == 0.25;
+}
`;
assert_equals(await callBoolFunction(program, "foo", []), true);
@@ -44,6 +48,7 @@
assert_equals(await callFloatFunction(program, "foo9", []), 7.5);
assert_equals(await callFloatFunction(program, "foo12", []), 7);
assert_equals(await callFloatFunction(program, "foo13", []), 7.5);
+assert_equals(await callBoolFunction(program, "div", []), true);
await checkFail(
`
Modified: trunk/Source/WebCore/ChangeLog (247553 => 247554)
--- trunk/Source/WebCore/ChangeLog 2019-07-18 02:00:06 UTC (rev 247553)
+++ trunk/Source/WebCore/ChangeLog 2019-07-18 02:29:54 UTC (rev 247554)
@@ -1,3 +1,27 @@
+2019-07-17 Robin Morisset
+
+[WHLSL] The lexer should not choke on a single '/'
+https://bugs.webkit.org/show_bug.cgi?id=199886
+
+Reviewed by Myles Maxfield.
+
+The bug is trivial: just recognize that a single '/' without a '*' or '/' afterwards is not the beginning of a comment.
+
+While investigating this bug, I also found that part of the parser fails to properly propagate errors, so I fixed it.
+
+New test in LayoutTests/webgpu/whlsl/float-math.html
+I also added a new flag to WHLSLPrepare.cpp. It can be used to parse the full standard library (this is how I found this bug in the first place).
+
+* Modules/webgpu/WHLSL/WHLSLLexer.cpp:
+(WebCore::WHLSL::Lexer::skipWhitespaceAndComments):
+* Modules/webgpu/WHLSL/WHLSLParser.cpp:
+(WebCore::WHLSL::Parser::parsePossibleTernaryConditional):
+* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
+(WebCore::WHLSL::prepareShared):
+* Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.cpp:
+(WebCore::WHLSL::includeStandardLibrary):
+* Modules/webgpu/WHLSL/WHLSLStandardLibraryUtilities.h:
+
2019-07-17 Simon Fraser
Unreviewed build fix after r247549.
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp (247553 => 247554)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp 2019-07-18 02:00:06 UTC (rev 247553)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp 2019-07-18 02:29:54 UTC (rev 247554)
@@ -558,7 +558,8 @@
break;
}
}
-}
+}
[webkit-changes] [247551] trunk/Source/WebCore
Title: [247551] trunk/Source/WebCore
Revision 247551
Author rmoris...@apple.com
Date 2019-07-17 18:18:55 -0700 (Wed, 17 Jul 2019)
Log Message
[WHLSL] Remove traps from the compiler
https://bugs.webkit.org/show_bug.cgi?id=195811
Reviewed by Myles Maxfield.
Remove the Trap statement from the language, see https://github.com/gpuweb/WHLSL/issues/301.
No new tests, as this part of the language was already untested, and we are removing it, not adding anything.
* Modules/webgpu/WHLSL/AST/WHLSLAST.h:
* Modules/webgpu/WHLSL/AST/WHLSLStatement.h:
(WebCore::WHLSL::AST::Statement::isSwitchStatement const):
* Modules/webgpu/WHLSL/AST/WHLSLTrap.h: Removed.
* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
* Modules/webgpu/WHLSL/WHLSLASTDumper.cpp:
* Modules/webgpu/WHLSL/WHLSLASTDumper.h:
* Modules/webgpu/WHLSL/WHLSLLexer.cpp:
(WebCore::WHLSL::Token::typeName):
(WebCore::WHLSL::Lexer::recognizeKeyword):
* Modules/webgpu/WHLSL/WHLSLLexer.h:
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseStatement):
* Modules/webgpu/WHLSL/WHLSLParser.h:
* Modules/webgpu/WHLSL/WHLSLStatementBehaviorChecker.cpp:
* Modules/webgpu/WHLSL/WHLSLVisitor.cpp:
(WebCore::WHLSL::Visitor::visit):
* Modules/webgpu/WHLSL/WHLSLVisitor.h:
* WebCore.xcodeproj/project.pbxproj:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLASTDumper.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLASTDumper.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStatementBehaviorChecker.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLVisitor.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLVisitor.h
trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj
Removed Paths
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTrap.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (247550 => 247551)
--- trunk/Source/WebCore/ChangeLog 2019-07-18 01:05:51 UTC (rev 247550)
+++ trunk/Source/WebCore/ChangeLog 2019-07-18 01:18:55 UTC (rev 247551)
@@ -1,5 +1,37 @@
2019-07-17 Robin Morisset
+[WHLSL] Remove traps from the compiler
+https://bugs.webkit.org/show_bug.cgi?id=195811
+
+
+Reviewed by Myles Maxfield.
+
+Remove the Trap statement from the language, see https://github.com/gpuweb/WHLSL/issues/301.
+
+No new tests, as this part of the language was already untested, and we are removing it, not adding anything.
+
+* Modules/webgpu/WHLSL/AST/WHLSLAST.h:
+* Modules/webgpu/WHLSL/AST/WHLSLStatement.h:
+(WebCore::WHLSL::AST::Statement::isSwitchStatement const):
+* Modules/webgpu/WHLSL/AST/WHLSLTrap.h: Removed.
+* Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp:
+* Modules/webgpu/WHLSL/WHLSLASTDumper.cpp:
+* Modules/webgpu/WHLSL/WHLSLASTDumper.h:
+* Modules/webgpu/WHLSL/WHLSLLexer.cpp:
+(WebCore::WHLSL::Token::typeName):
+(WebCore::WHLSL::Lexer::recognizeKeyword):
+* Modules/webgpu/WHLSL/WHLSLLexer.h:
+* Modules/webgpu/WHLSL/WHLSLParser.cpp:
+(WebCore::WHLSL::Parser::parseStatement):
+* Modules/webgpu/WHLSL/WHLSLParser.h:
+* Modules/webgpu/WHLSL/WHLSLStatementBehaviorChecker.cpp:
+* Modules/webgpu/WHLSL/WHLSLVisitor.cpp:
+(WebCore::WHLSL::Visitor::visit):
+* Modules/webgpu/WHLSL/WHLSLVisitor.h:
+* WebCore.xcodeproj/project.pbxproj:
+
+2019-07-17 Robin Morisset
+
[WHLSL] checkRecursiveType should not have exponential complexity.
https://bugs.webkit.org/show_bug.cgi?id=199835
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h (247550 => 247551)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h 2019-07-18 01:05:51 UTC (rev 247550)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h 2019-07-18 01:18:55 UTC (rev 247551)
@@ -90,7 +90,6 @@
#include "WHLSLSwitchCase.h"
#include "WHLSLSwitchStatement.h"
#include "WHLSLTernaryExpression.h"
-#include "WHLSLTrap.h"
#include "WHLSLType.h"
#include "WHLSLTypeArgument.h"
#include "WHLSLTypeDefinition.h"
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.h (247550 => 247551)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.h 2019-07-18 01:05:51 UTC (rev 247550)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.h 2019-07-18 01:18:55 UTC (rev 247551)
@@ -60,7 +60,6 @@
virtual bool isStatementList() const { return false; }
virtual bool isSwitchCase() const { return false; }
virtual bool isSwitchStatement() const {
[webkit-changes] [247549] trunk/Source/WebCore
Title: [247549] trunk/Source/WebCore
Revision 247549
Author rmoris...@apple.com
Date 2019-07-17 17:36:39 -0700 (Wed, 17 Jul 2019)
Log Message
[WHLSL] checkRecursiveType should not have exponential complexity.
https://bugs.webkit.org/show_bug.cgi?id=199835
Reviewed by Myles Maxfield.
The change is very similar to that in https://bugs.webkit.org/show_bug.cgi?id=199688.
Just keep track of which types have already been visited, and don't visit them again.
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.cpp:
(WebCore::WHLSL::RecursiveTypeChecker::visit):
(WebCore::WHLSL::checkRecursiveTypes):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (247548 => 247549)
--- trunk/Source/WebCore/ChangeLog 2019-07-18 00:17:51 UTC (rev 247548)
+++ trunk/Source/WebCore/ChangeLog 2019-07-18 00:36:39 UTC (rev 247549)
@@ -1,3 +1,19 @@
+2019-07-17 Robin Morisset
+
+[WHLSL] checkRecursiveType should not have exponential complexity.
+https://bugs.webkit.org/show_bug.cgi?id=199835
+
+Reviewed by Myles Maxfield.
+
+The change is very similar to that in https://bugs.webkit.org/show_bug.cgi?id=199688.
+Just keep track of which types have already been visited, and don't visit them again.
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.cpp:
+(WebCore::WHLSL::RecursiveTypeChecker::visit):
+(WebCore::WHLSL::checkRecursiveTypes):
+
2019-07-17 Carlos Eduardo Ramalho
Add missing #include's
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.cpp (247548 => 247549)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.cpp 2019-07-18 00:17:51 UTC (rev 247548)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursiveTypeChecker.cpp 2019-07-18 00:36:39 UTC (rev 247549)
@@ -28,7 +28,6 @@
#if ENABLE(WEBGPU)
-#include "WHLSLScopedSetAdder.h"
#include "WHLSLStructureDefinition.h"
#include "WHLSLTypeDefinition.h"
#include "WHLSLTypeReference.h"
@@ -41,8 +40,6 @@
class RecursiveTypeChecker : public Visitor {
public:
-virtual ~RecursiveTypeChecker() = default;
-
void visit(AST::TypeDefinition&) override;
void visit(AST::StructureDefinition&) override;
void visit(AST::TypeReference&) override;
@@ -49,44 +46,55 @@
void visit(AST::ReferenceType&) override;
private:
-using Adder = ScopedSetAdder;
-HashSet m_types;
+HashSet m_startedVisiting;
+HashSet m_finishedVisiting;
};
+#define START_VISITING(t) \
+do { \
+if (m_finishedVisiting.contains(t)) \
+return; \
+auto resultStartedVisiting = m_startedVisiting.add(t); \
+if (!resultStartedVisiting.isNewEntry) { \
+setError(); \
+return; \
+} \
+} while (false);
+
+#define END_VISITING(t) \
+do { \
+auto resultFinishedVisiting = m_finishedVisiting.add(t); \
+ASSERT_UNUSED(resultFinishedVisiting, resultFinishedVisiting.isNewEntry); \
+} while (false);
+
void RecursiveTypeChecker::visit(AST::TypeDefinition& typeDefinition)
{
-Adder adder(m_types, );
-if (!adder.isNewEntry()) {
-setError();
-return;
-}
+START_VISITING();
Visitor::visit(typeDefinition);
+
+END_VISITING();
}
void RecursiveTypeChecker::visit(AST::StructureDefinition& structureDefinition)
{
-Adder adder(m_types, );
-if (!adder.isNewEntry()) {
-setError();
-return;
-}
+START_VISITING();
Visitor::visit(structureDefinition);
+
+END_VISITING();
}
void RecursiveTypeChecker::visit(AST::TypeReference& typeReference)
{
-Adder adder(m_types, );
-if (!adder.isNewEntry()) {
-setError();
-return;
-}
+START_VISITING();
for (auto& typeArgument : typeReference.typeArguments())
checkErrorAndVisit(typeArgument);
if (typeReference.maybeResolvedType()) // FIXME: https://bugs.webkit.org/show_bug.cgi?id=198161 Shouldn't we know by now whether the type has been resolved or not?
checkErrorAndVisit(typeReference.resolvedType());
+
+END_VISITING();
}
void RecursiveTypeChecker::visit(AST::ReferenceType&)
@@ -96,7 +104,10 @@
bool checkRecursiveTypes(Program& program)
{
RecursiveTypeChecker recursiveTypeChecker;
-recursiveTypeChecker.checkErrorAndVisit(program);
+for (auto& typeDefinition : program.typeDefinitions())
+recursiveTypeChecker.checkErrorAndVisit(typeDefinition);
+for (auto& structureDefinition : program.structureDefinitions())
+recursiveTypeChecker.checkErrorAndVisit(structureDefinition);
return !recursiveTypeChecker.error();
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
[webkit-changes] [247493] trunk
Title: [247493] trunk Revision 247493 Author rmoris...@apple.com Date 2019-07-16 13:26:01 -0700 (Tue, 16 Jul 2019) Log Message [WHLSL] Desugar for loops and while loops https://bugs.webkit.org/show_bug.cgi?id=199726 Reviewed by Myles C. Maxfield. Source/WebCore: This patch makes loops behave a lot more similarly to the spec. In particular, while loops are just degenerate for loops, so they can be desugared in the parser. And for loops can themselves be heavily desugared, into having no initializer, one condition and one increment by putting any initializer in a block around the loop, putting true in the condition if there is none, and putting any litteral in the increment if there is none. Debugging this patch revealed an unrelated bug where the parser would generate an empty comma _expression_ on ";", which the checker would then choke on. The parser now generates an empty block in that case (as specified in the spec), which fixes the problem. Finally, while updating the NameResolver for the new structure of loops I realized that it was needlessly generating extra NameContext. They are not expected by the spec, that forbids naked variable declarations outside of blocks anyway. So I removed this unnecessary work, and fixed the parser to correctly forbid such naked variable declarations. * Modules/webgpu/WHLSL/AST/WHLSLAST.h: * Modules/webgpu/WHLSL/AST/WHLSLForLoop.h: (WebCore::WHLSL::AST::ForLoop::ForLoop): (WebCore::WHLSL::AST::ForLoop::condition): (WebCore::WHLSL::AST::ForLoop::increment): * Modules/webgpu/WHLSL/AST/WHLSLStatement.h: (WebCore::WHLSL::AST::Statement::isVariableDeclarationsStatement const): * Modules/webgpu/WHLSL/AST/WHLSLWhileLoop.h: Removed. * Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp: (WebCore::WHLSL::Metal::FunctionDefinitionWriter::visit): * Modules/webgpu/WHLSL/WHLSLASTDumper.cpp: (WebCore::WHLSL::ASTDumper::visit): * Modules/webgpu/WHLSL/WHLSLASTDumper.h: * Modules/webgpu/WHLSL/WHLSLChecker.cpp: (WebCore::WHLSL::Checker::visit): * Modules/webgpu/WHLSL/WHLSLNameResolver.cpp: (WebCore::WHLSL::NameResolver::visit): * Modules/webgpu/WHLSL/WHLSLNameResolver.h: * Modules/webgpu/WHLSL/WHLSLParser.cpp: (WebCore::WHLSL::Parser::parseBlockBody): (WebCore::WHLSL::Parser::parseForLoop): (WebCore::WHLSL::Parser::parseWhileLoop): (WebCore::WHLSL::Parser::parseStatement): (WebCore::WHLSL::Parser::parseEffectfulExpression): * Modules/webgpu/WHLSL/WHLSLParser.h: * Modules/webgpu/WHLSL/WHLSLStatementBehaviorChecker.cpp: * Modules/webgpu/WHLSL/WHLSLVisitor.cpp: (WebCore::WHLSL::Visitor::visit): * Modules/webgpu/WHLSL/WHLSLVisitor.h: * WebCore.xcodeproj/project.pbxproj: LayoutTests: I added the for-loop tests from Test.mjs (with help from Saam). I did not add the foo9 and foo10 tests, as they are forbidden by the behavior checker in the C++ implementation (and by the spec). I also changed one test from whlsl-return-spec-tests.html to assert_fail, because it relied on a lone variable declaration in an if, which is forbidden by the spec. * webgpu/whlsl-for-loop-expected.txt: Added. * webgpu/whlsl-for-loop.html: Added. * webgpu/whlsl-return-spec-tests.html: Modified Paths trunk/LayoutTests/ChangeLog trunk/LayoutTests/webgpu/whlsl-return-spec-tests.html trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.h trunk/Source/WebCore/Modules/webgpu/WHLSL/Metal/WHLSLFunctionWriter.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLASTDumper.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLASTDumper.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStatementBehaviorChecker.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLVisitor.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLVisitor.h trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj Added Paths trunk/LayoutTests/webgpu/whlsl-for-loop-expected.txt trunk/LayoutTests/webgpu/whlsl-for-loop.html Removed Paths trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLWhileLoop.h Diff Modified: trunk/LayoutTests/ChangeLog (247492 => 247493) --- trunk/LayoutTests/ChangeLog 2019-07-16 20:17:39 UTC (rev 247492) +++ trunk/LayoutTests/ChangeLog 2019-07-16 20:26:01 UTC (rev 247493) @@ -1,3 +1,19 @@ +2019-07-16 Robin Morisset + +[WHLSL] Desugar for loops and while loops +https://bugs.webkit.org/show_bug.cgi?id=199726 + +Reviewed by Myles C. Maxfield. + +I added the for-loop tests from Test.mjs (with help from Saam). +I did not add the foo9 and foo10 tests, as they are forbidden by the behavior checker in the C++ implementation (and by the
[webkit-changes] [247419] trunk/Source/WebCore
Title: [247419] trunk/Source/WebCore
Revision 247419
Author rmoris...@apple.com
Date 2019-07-13 10:43:41 -0700 (Sat, 13 Jul 2019)
Log Message
[WHLSL] Return statements don't need to keep track of the function they're in
https://bugs.webkit.org/show_bug.cgi?id=199763
Reviewed by Myles C. Maxfield.
Return::m_function is only used in the Checker, and it can easily enough keep track of the current function.
This means we no longer need to keep track of the current function in the NameResolver, and we can save 8 bytes per Return
Since I was touching the NameResolver I also removed a few pointless overrides of Visitor::visit().
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/AST/WHLSLReturn.h:
* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
(WebCore::WHLSL::Checker::visit):
* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
(WebCore::WHLSL::NameResolver::NameResolver):
(WebCore::WHLSL::resolveTypeNamesInFunctions):
* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReturn.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (247418 => 247419)
--- trunk/Source/WebCore/ChangeLog 2019-07-13 17:28:41 UTC (rev 247418)
+++ trunk/Source/WebCore/ChangeLog 2019-07-13 17:43:41 UTC (rev 247419)
@@ -1,3 +1,25 @@
+2019-07-13 Robin Morisset
+
+[WHLSL] Return statements don't need to keep track of the function they're in
+https://bugs.webkit.org/show_bug.cgi?id=199763
+
+Reviewed by Myles C. Maxfield.
+
+Return::m_function is only used in the Checker, and it can easily enough keep track of the current function.
+This means we no longer need to keep track of the current function in the NameResolver, and we can save 8 bytes per Return
+
+Since I was touching the NameResolver I also removed a few pointless overrides of Visitor::visit().
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/AST/WHLSLReturn.h:
+* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
+(WebCore::WHLSL::Checker::visit):
+* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
+(WebCore::WHLSL::NameResolver::NameResolver):
+(WebCore::WHLSL::resolveTypeNamesInFunctions):
+* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
+
2019-07-13 Andres Gonzalez
Add accessibility support to WKDataListSuggestionsView.
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReturn.h (247418 => 247419)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReturn.h 2019-07-13 17:28:41 UTC (rev 247418)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReturn.h 2019-07-13 17:43:41 UTC (rev 247419)
@@ -56,12 +56,8 @@
_expression_* value() { return m_value.get(); }
-FunctionDefinition* function() { return m_function; }
-void setFunction(FunctionDefinition* functionDefinition) { m_function = functionDefinition; }
-
private:
std::unique_ptr<_expression_> m_value;
-FunctionDefinition* m_function { nullptr };
};
} // namespace AST
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp (247418 => 247419)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp 2019-07-13 17:28:41 UTC (rev 247418)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp 2019-07-13 17:43:41 UTC (rev 247419)
@@ -517,6 +517,7 @@
HashSet m_computeEntryPoints;
const Intrinsics& m_intrinsics;
Program& m_program;
+AST::FunctionDefinition* m_currentFunction { nullptr };
};
void Checker::visit(Program& program)
@@ -572,6 +573,7 @@
void Checker::visit(AST::FunctionDefinition& functionDefinition)
{
+m_currentFunction =
if (functionDefinition.entryPointType()) {
if (!checkShaderType(functionDefinition)) {
setError();
@@ -1144,12 +1146,12 @@
auto valueInfo = recurseAndGetInfo(*returnStatement.value());
if (!valueInfo)
return;
-if (!matchAndCommit(valueInfo->resolvingType, returnStatement.function()->type()))
+if (!matchAndCommit(valueInfo->resolvingType, m_currentFunction->type()))
setError();
return;
}
-if (!matches(returnStatement.function()->type(), m_intrinsics.voidType()))
+if (!matches(m_currentFunction->type(), m_intrinsics.voidType()))
setError();
}
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp (247418 => 247419)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp 2019-07-13 17:28:41 UTC (rev 247418)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp 2019-07-13 17:43:41 UTC (rev 247419)
@@ -28,7 +28,6 @@
#if ENABLE(WEBGPU)
-#include "WHLSLCallExpression.h"
#include
[webkit-changes] [247341] trunk/Source/WebCore
Title: [247341] trunk/Source/WebCore
Revision 247341
Author rmoris...@apple.com
Date 2019-07-10 19:09:52 -0700 (Wed, 10 Jul 2019)
Log Message
[WHLSL] Optional> -> std::unique_ptr in Return/IfStatement/ForLoop
https://bugs.webkit.org/show_bug.cgi?id=199695
Reviewed by Dean Jackson.
Trivial patch that saves 8 bytes per Return/If, and 16 bytes per For loop.
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/AST/WHLSLForLoop.h:
(WebCore::WHLSL::AST::ForLoop::ForLoop):
(WebCore::WHLSL::AST::ForLoop::condition):
(WebCore::WHLSL::AST::ForLoop::increment):
* Modules/webgpu/WHLSL/AST/WHLSLIfStatement.h:
(WebCore::WHLSL::AST::IfStatement::IfStatement):
(WebCore::WHLSL::AST::IfStatement::elseBody):
* Modules/webgpu/WHLSL/AST/WHLSLReturn.h:
(WebCore::WHLSL::AST::Return::Return):
(WebCore::WHLSL::AST::Return::value):
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseIfStatement):
(WebCore::WHLSL::Parser::parseForLoop):
(WebCore::WHLSL::Parser::parseStatement):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIfStatement.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReturn.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (247340 => 247341)
--- trunk/Source/WebCore/ChangeLog 2019-07-11 01:27:04 UTC (rev 247340)
+++ trunk/Source/WebCore/ChangeLog 2019-07-11 02:09:52 UTC (rev 247341)
@@ -1,5 +1,31 @@
2019-07-10 Robin Morisset
+[WHLSL] Optional> -> std::unique_ptr in Return/IfStatement/ForLoop
+https://bugs.webkit.org/show_bug.cgi?id=199695
+
+Reviewed by Dean Jackson.
+
+Trivial patch that saves 8 bytes per Return/If, and 16 bytes per For loop.
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/AST/WHLSLForLoop.h:
+(WebCore::WHLSL::AST::ForLoop::ForLoop):
+(WebCore::WHLSL::AST::ForLoop::condition):
+(WebCore::WHLSL::AST::ForLoop::increment):
+* Modules/webgpu/WHLSL/AST/WHLSLIfStatement.h:
+(WebCore::WHLSL::AST::IfStatement::IfStatement):
+(WebCore::WHLSL::AST::IfStatement::elseBody):
+* Modules/webgpu/WHLSL/AST/WHLSLReturn.h:
+(WebCore::WHLSL::AST::Return::Return):
+(WebCore::WHLSL::AST::Return::value):
+* Modules/webgpu/WHLSL/WHLSLParser.cpp:
+(WebCore::WHLSL::Parser::parseIfStatement):
+(WebCore::WHLSL::Parser::parseForLoop):
+(WebCore::WHLSL::Parser::parseStatement):
+
+2019-07-10 Robin Morisset
+
[WHLSL] The recursion checker should not have quadratic complexity
https://bugs.webkit.org/show_bug.cgi?id=199688
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h (247340 => 247341)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h 2019-07-11 01:27:04 UTC (rev 247340)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLForLoop.h 2019-07-11 02:09:52 UTC (rev 247341)
@@ -44,7 +44,7 @@
class ForLoop : public Statement {
public:
-ForLoop(CodeLocation location, Variant, UniqueRef<_expression_>>&& initialization, Optional>&& condition, Optional>&& increment, UniqueRef&& body)
+ForLoop(CodeLocation location, Variant, UniqueRef<_expression_>>&& initialization, std::unique_ptr<_expression_>&& condition, std::unique_ptr<_expression_>&& increment, UniqueRef&& body)
: Statement(location)
, m_initialization(WTFMove(initialization))
, m_condition(WTFMove(condition))
@@ -63,14 +63,14 @@
bool isForLoop() const override { return true; }
Variant, UniqueRef<_expression_>>& initialization() { return m_initialization; }
-_expression_* condition() { return m_condition ? &*m_condition : nullptr; }
-_expression_* increment() { return m_increment ? &*m_increment : nullptr; }
+_expression_* condition() { return m_condition.get(); }
+_expression_* increment() { return m_increment.get(); }
Statement& body() { return m_body; }
private:
Variant, UniqueRef<_expression_>> m_initialization;
-Optional> m_condition;
-Optional> m_increment;
+std::unique_ptr<_expression_> m_condition;
+std::unique_ptr<_expression_> m_increment;
UniqueRef m_body;
};
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIfStatement.h (247340 => 247341)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIfStatement.h 2019-07-11 01:27:04 UTC (rev 247340)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLIfStatement.h 2019-07-11 02:09:52 UTC (rev 247341)
@@ -41,7 +41,7 @@
class IfStatement : public Statement {
public:
-IfStatement(CodeLocation location, UniqueRef<_expression_>&& conditional, UniqueRef&& body, Optional>&& elseBody)
+IfStatement(CodeLocation location, UniqueRef<_expression_>&& conditional, UniqueRef&& body, std::unique_ptr&& elseBody)
:
[webkit-changes] [247339] trunk/Source/WebCore
Title: [247339] trunk/Source/WebCore
Revision 247339
Author rmoris...@apple.com
Date 2019-07-10 18:18:14 -0700 (Wed, 10 Jul 2019)
Log Message
[WHLSL] The recursion checker should not have quadratic complexity
https://bugs.webkit.org/show_bug.cgi?id=199688
Reviewed by Saam Barati.
I fix it by using two different hash sets, tracking which functions we have started visiting, and which we have finished visiting.
The difference are those that are currently "on the stack", and calling any of those is an error.
As a bonus, I also overrode visit(Program&), so that we only bother visiting function definitions.
On whlsl-compute.html ran 5 times, this patch reduces the time spent in the recursion checker from 26ms to 12ms.
It is likely to be a much bigger win on larger programs (since it took the complexity from quadratic to linear).
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/WHLSLRecursionChecker.cpp:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursionChecker.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (247338 => 247339)
--- trunk/Source/WebCore/ChangeLog 2019-07-11 00:59:10 UTC (rev 247338)
+++ trunk/Source/WebCore/ChangeLog 2019-07-11 01:18:14 UTC (rev 247339)
@@ -1,3 +1,21 @@
+2019-07-10 Robin Morisset
+
+[WHLSL] The recursion checker should not have quadratic complexity
+https://bugs.webkit.org/show_bug.cgi?id=199688
+
+Reviewed by Saam Barati.
+
+I fix it by using two different hash sets, tracking which functions we have started visiting, and which we have finished visiting.
+The difference are those that are currently "on the stack", and calling any of those is an error.
+As a bonus, I also overrode visit(Program&), so that we only bother visiting function definitions.
+
+On whlsl-compute.html ran 5 times, this patch reduces the time spent in the recursion checker from 26ms to 12ms.
+It is likely to be a much bigger win on larger programs (since it took the complexity from quadratic to linear).
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/WHLSLRecursionChecker.cpp:
+
2019-07-10 Sihui Liu
Crash at WebCore::IDBServer::MemoryObjectStoreCursor::incrementReverseIterator
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursionChecker.cpp (247338 => 247339)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursionChecker.cpp 2019-07-11 00:59:10 UTC (rev 247338)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLRecursionChecker.cpp 2019-07-11 01:18:14 UTC (rev 247339)
@@ -40,9 +40,18 @@
// Makes sure there is no function recursion.
class RecursionChecker : public Visitor {
private:
+void visit(Program& program) override
+{
+for (auto& functionDefinition : program.functionDefinitions())
+checkErrorAndVisit(functionDefinition);
+}
+
void visit(AST::FunctionDefinition& functionDefinition) override
{
-auto addResult = m_visitingSet.add();
+if (m_finishedVisiting.contains())
+return;
+
+auto addResult = m_startedVisiting.add();
if (!addResult.isNewEntry) {
setError();
return;
@@ -49,11 +58,11 @@
}
Visitor::visit(functionDefinition);
-if (error())
-return;
-auto success = m_visitingSet.remove();
-ASSERT_UNUSED(success, success);
+{
+auto addResult = m_finishedVisiting.add();
+ASSERT_UNUSED(addResult, addResult.isNewEntry);
+}
}
void visit(AST::CallExpression& callExpression) override
@@ -63,7 +72,8 @@
checkErrorAndVisit(downcast(callExpression.function()));
}
-HashSet m_visitingSet;
+HashSet m_startedVisiting;
+HashSet m_finishedVisiting;
};
bool checkRecursion(Program& program)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [247189] trunk/Source/WebCore
Title: [247189] trunk/Source/WebCore
Revision 247189
Author rmoris...@apple.com
Date 2019-07-05 17:33:01 -0700 (Fri, 05 Jul 2019)
Log Message
[WHLSL] The checker does not need to keep a separate m_typeAnnotations map
https://bugs.webkit.org/show_bug.cgi?id=199537
Reviewed by Myles C. Maxfield.
Nothing is ever deleted from it, and all of its contents are eventually copied into the expressions.
We might as well put the type annotations directly into the expressions in the first place.
It is about a 5% speedup of the checker.
No new test as there is no inteded functional change.
* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
(WebCore::WHLSL::Checker::assignTypes):
(WebCore::WHLSL::Checker::getInfo):
(WebCore::WHLSL::Checker::assignType):
(WebCore::WHLSL::Checker::forwardType):
(WebCore::WHLSL::Checker::visit):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (247188 => 247189)
--- trunk/Source/WebCore/ChangeLog 2019-07-05 23:46:34 UTC (rev 247188)
+++ trunk/Source/WebCore/ChangeLog 2019-07-06 00:33:01 UTC (rev 247189)
@@ -1,3 +1,23 @@
+2019-07-05 Robin Morisset
+
+[WHLSL] The checker does not need to keep a separate m_typeAnnotations map
+https://bugs.webkit.org/show_bug.cgi?id=199537
+
+Reviewed by Myles C. Maxfield.
+
+Nothing is ever deleted from it, and all of its contents are eventually copied into the expressions.
+We might as well put the type annotations directly into the expressions in the first place.
+It is about a 5% speedup of the checker.
+
+No new test as there is no inteded functional change.
+
+* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
+(WebCore::WHLSL::Checker::assignTypes):
+(WebCore::WHLSL::Checker::getInfo):
+(WebCore::WHLSL::Checker::assignType):
+(WebCore::WHLSL::Checker::forwardType):
+(WebCore::WHLSL::Checker::visit):
+
2019-07-05 Youenn Fablet and Simon Fraser
Trigger a compositing update when video element is changing
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp (247188 => 247189)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp 2019-07-05 23:46:34 UTC (rev 247188)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp 2019-07-06 00:33:01 UTC (rev 247189)
@@ -512,7 +512,6 @@
void finishVisiting(AST::PropertyAccessExpression&, ResolvingType* additionalArgumentType = nullptr);
HashMap> m_typeMap;
-HashMap m_typeAnnotations;
HashSet m_vertexEntryPoints;
HashSet m_fragmentEntryPoints;
HashSet m_computeEntryPoints;
@@ -556,8 +555,6 @@
return false;
}
-for (auto& keyValuePair : m_typeAnnotations)
-keyValuePair.key->setTypeAnnotation(WTFMove(keyValuePair.value));
return true;
}
@@ -778,13 +775,12 @@
auto typeIterator = m_typeMap.find(&_expression_);
ASSERT(typeIterator != m_typeMap.end());
-auto typeAnnotationIterator = m_typeAnnotations.find(&_expression_);
-ASSERT(typeAnnotationIterator != m_typeAnnotations.end());
-if (requiresLeftValue && typeAnnotationIterator->value.isRightValue()) {
+const auto& typeAnnotation = _expression_.typeAnnotation();
+if (requiresLeftValue && typeAnnotation.isRightValue()) {
setError();
return WTF::nullopt;
}
-return {{ *typeIterator->value, typeAnnotationIterator->value }};
+return {{ *typeIterator->value, typeAnnotation }};
}
void Checker::visit(AST::VariableDeclaration& variableDeclaration)
@@ -808,8 +804,7 @@
{
auto addResult = m_typeMap.add(&_expression_, std::make_unique(WTFMove(unnamedType)));
ASSERT_UNUSED(addResult, addResult.isNewEntry);
-auto typeAnnotationAddResult = m_typeAnnotations.add(&_expression_, WTFMove(typeAnnotation));
-ASSERT_UNUSED(typeAnnotationAddResult, typeAnnotationAddResult.isNewEntry);
+_expression_.setTypeAnnotation(WTFMove(typeAnnotation));
}
void Checker::assignType(AST::_expression_& _expression_, RefPtr&& resolvableTypeReference, AST::TypeAnnotation typeAnnotation = AST::RightValue())
@@ -816,8 +811,7 @@
{
auto addResult = m_typeMap.add(&_expression_, std::make_unique(WTFMove(resolvableTypeReference)));
ASSERT_UNUSED(addResult, addResult.isNewEntry);
-auto typeAnnotationAddResult = m_typeAnnotations.add(&_expression_, WTFMove(typeAnnotation));
-ASSERT_UNUSED(typeAnnotationAddResult, typeAnnotationAddResult.isNewEntry);
+_expression_.setTypeAnnotation(WTFMove(typeAnnotation));
}
void Checker::forwardType(AST::_expression_& _expression_, ResolvingType& resolvingType, AST::TypeAnnotation typeAnnotation = AST::RightValue())
@@ -829,8 +823,7 @@
auto addResult = m_typeMap.add(&_expression_, std::make_unique(result.copyRef()));
ASSERT_UNUSED(addResult, addResult.isNewEntry);
}));
-auto typeAnnotationAddResult =
[webkit-changes] [247171] trunk/Source/WebCore
Title: [247171] trunk/Source/WebCore Revision 247171 Author rmoris...@apple.com Date 2019-07-05 13:10:36 -0700 (Fri, 05 Jul 2019) Log Message [WHLSL] Optimize the lexer https://bugs.webkit.org/show_bug.cgi?id=199520 Reviewed by Myles Maxfield. This patch includes a number of small optimizations to the lexer: - By creating two new types of Token (Invalid and EOF), we can avoid having to manipulate Optional everywhere - By combining the lexing of identifiers, keywords and operator names, we can avoid re-reading them several times - By storing mere offsets in the tokens instead of string views, we save space in the common case where the string view is unused (e.g. for keywords) - By storing mere offsets in the tokens instead of line numbers, we can simplify the whitespace and comment lexing; and we can easily recompute the line number on demand - By using templates we can avoid constructing and destructing vectors at runtime every time we call tryTypes, consumeTypes or peekTypes; as well as avoiding a call to find(). - I also hoisted the length check out of the loop in Lexer::string() All of this combined brought the time spent in the parser when running LayoutTests/webgpu/whlsl-test-harness-test.html 5 times on my machine from 612ms to 462ms. I also removed the 'anyCharacter' method since it was dead code. I also removed Lexer::position(), but it is directly equivalent now to peek().startOffset. No new tests as there is no intended functional change. * Modules/webgpu/WHLSL/WHLSLLexer.cpp: (WebCore::WHLSL::Lexer::Token::typeName): (WebCore::WHLSL::Lexer::consumeTokenFromStream): (WebCore::WHLSL::Lexer::lineNumberFromOffset): (WebCore::WHLSL::isWhitespace): (WebCore::WHLSL::isNewline): (WebCore::WHLSL::Lexer::skipWhitespaceAndComments): (WebCore::WHLSL::Lexer::digitStar const): (WebCore::WHLSL::Lexer::completeOperatorName const): * Modules/webgpu/WHLSL/WHLSLLexer.h: (WebCore::WHLSL::Lexer::Lexer): (WebCore::WHLSL::Lexer::Token::stringView): (WebCore::WHLSL::Lexer::consumeToken): (WebCore::WHLSL::Lexer::peek const): (WebCore::WHLSL::Lexer::peekFurther const): (WebCore::WHLSL::Lexer::state const): (WebCore::WHLSL::Lexer::setState): (WebCore::WHLSL::Lexer::isFullyConsumed const): (WebCore::WHLSL::Lexer::errorString): (WebCore::WHLSL::Lexer::string const): * Modules/webgpu/WHLSL/WHLSLNameResolver.h: * Modules/webgpu/WHLSL/WHLSLParser.cpp: (WebCore::WHLSL::Parser::parse): (WebCore::WHLSL::Parser::peek): (WebCore::WHLSL::Parser::peekFurther): (WebCore::WHLSL::Types::includes): (WebCore::WHLSL::Types::appendNameTo): (WebCore::WHLSL::Types::includes): (WebCore::WHLSL::Types::appendNameTo): (WebCore::WHLSL::Parser::peekTypes): (WebCore::WHLSL::Parser::tryType): (WebCore::WHLSL::Parser::tryTypes): (WebCore::WHLSL::Parser::consumeType): (WebCore::WHLSL::Parser::consumeTypes): (WebCore::WHLSL::Parser::consumeIntegralLiteral): (WebCore::WHLSL::Parser::parseConstantExpression): (WebCore::WHLSL::Parser::parseTypeArgument): (WebCore::WHLSL::Parser::parseTypeSuffixAbbreviated): (WebCore::WHLSL::Parser::parseTypeSuffixNonAbbreviated): (WebCore::WHLSL::Parser::parseType): (WebCore::WHLSL::Parser::parseTypeDefinition): (WebCore::WHLSL::Parser::parseBuiltInSemantic): (WebCore::WHLSL::Parser::parseResourceSemantic): (WebCore::WHLSL::Parser::parseQualifiers): (WebCore::WHLSL::Parser::parseStructureElement): (WebCore::WHLSL::Parser::parseStructureDefinition): (WebCore::WHLSL::Parser::parseEnumerationDefinition): (WebCore::WHLSL::Parser::parseEnumerationMember): (WebCore::WHLSL::Parser::parseNativeTypeDeclaration): (WebCore::WHLSL::Parser::parseParameter): (WebCore::WHLSL::Parser::parseComputeFunctionDeclaration): (WebCore::WHLSL::Parser::parseVertexOrFragmentFunctionDeclaration): (WebCore::WHLSL::Parser::parseRegularFunctionDeclaration): (WebCore::WHLSL::Parser::parseBlockBody): (WebCore::WHLSL::Parser::parseSwitchCase): (WebCore::WHLSL::Parser::parseVariableDeclaration): (WebCore::WHLSL::Parser::parseStatement): (WebCore::WHLSL::Parser::parseEffectfulAssignment): (WebCore::WHLSL::Parser::parseLimitedSuffixOperator): (WebCore::WHLSL::Parser::parseSuffixOperator): (WebCore::WHLSL::Parser::completeAssignment): (WebCore::WHLSL::Parser::parsePossibleTernaryConditional): (WebCore::WHLSL::Parser::completePossibleLogicalBinaryOperation): (WebCore::WHLSL::Parser::completePossibleRelationalBinaryOperation): (WebCore::WHLSL::Parser::completePossibleShift): (WebCore::WHLSL::Parser::completePossibleAdd): (WebCore::WHLSL::Parser::completePossibleMultiply): (WebCore::WHLSL::Parser::parsePossiblePrefix): (WebCore::WHLSL::Parser::parseCallExpression): (WebCore::WHLSL::Parser::parseTerm): * Modules/webgpu/WHLSL/WHLSLParser.h: * Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp: (WebCore::WHLSL::anonymousToken): Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLLexer.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h
[webkit-changes] [247170] trunk/Source/WebCore
Title: [247170] trunk/Source/WebCore
Revision 247170
Author rmoris...@apple.com
Date 2019-07-05 13:09:39 -0700 (Fri, 05 Jul 2019)
Log Message
[WHLSL] Remove the phase resolveCallsInFunctions
https://bugs.webkit.org/show_bug.cgi?id=199474
Reviewed by Myles Maxfield.
This pass only stores into each property access and call _expression_ vectors of all the functions it might be calling, for use by the Checker afterwards.
But the checker is perfectly able to compute a pointer to these vectors by itself.
So by removing this pass, we gain the following:
- One less pass over the AST
- No need to copy these vectors (which can be large for heavily overloaded functions, of which there are quite a few in the stdlib)
- No need to have these vectors in the expressions, saving 24 bytes per CallExpression and 72 bytes per PropertyAccessExpression
- No need to allocate and then destroy these vectors.
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h:
(WebCore::WHLSL::AST::CallExpression::castReturnType):
* Modules/webgpu/WHLSL/AST/WHLSLPropertyAccessExpression.h:
* Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp:
(WebCore::WHLSL::AutoInitialize::visit):
* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
(WebCore::WHLSL::resolveFunction):
(WebCore::WHLSL::Checker::finishVisiting):
(WebCore::WHLSL::Checker::visit):
* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
(WebCore::WHLSL::NameResolver::NameResolver):
(WebCore::WHLSL::NameResolver::visit):
* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
(WebCore::WHLSL::prepareShared):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLPropertyAccessExpression.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPrepare.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (247169 => 247170)
--- trunk/Source/WebCore/ChangeLog 2019-07-05 20:06:47 UTC (rev 247169)
+++ trunk/Source/WebCore/ChangeLog 2019-07-05 20:09:39 UTC (rev 247170)
@@ -1,3 +1,36 @@
+2019-07-05 Robin Morisset
+
+[WHLSL] Remove the phase resolveCallsInFunctions
+https://bugs.webkit.org/show_bug.cgi?id=199474
+
+Reviewed by Myles Maxfield.
+
+This pass only stores into each property access and call _expression_ vectors of all the functions it might be calling, for use by the Checker afterwards.
+But the checker is perfectly able to compute a pointer to these vectors by itself.
+So by removing this pass, we gain the following:
+- One less pass over the AST
+- No need to copy these vectors (which can be large for heavily overloaded functions, of which there are quite a few in the stdlib)
+- No need to have these vectors in the expressions, saving 24 bytes per CallExpression and 72 bytes per PropertyAccessExpression
+- No need to allocate and then destroy these vectors.
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h:
+(WebCore::WHLSL::AST::CallExpression::castReturnType):
+* Modules/webgpu/WHLSL/AST/WHLSLPropertyAccessExpression.h:
+* Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp:
+(WebCore::WHLSL::AutoInitialize::visit):
+* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
+(WebCore::WHLSL::resolveFunction):
+(WebCore::WHLSL::Checker::finishVisiting):
+(WebCore::WHLSL::Checker::visit):
+* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
+(WebCore::WHLSL::NameResolver::NameResolver):
+(WebCore::WHLSL::NameResolver::visit):
+* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
+* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
+(WebCore::WHLSL::prepareShared):
+
2019-07-05 Youenn Fablet
[iOS] Local capture MediaStreamTrack does not render in portrait mode
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h (247169 => 247170)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h 2019-07-05 20:06:47 UTC (rev 247169)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h 2019-07-05 20:09:39 UTC (rev 247170)
@@ -67,14 +67,6 @@
bool isCast() { return m_castReturnType; }
NamedType* castReturnType() { return m_castReturnType; }
-bool hasOverloads() const { return static_cast(m_overloads); }
-Optional, 1>>& overloads() { return m_overloads; }
-void setOverloads(const Vector, 1>& overloads)
-{
-assert(!hasOverloads());
-m_overloads =
[webkit-changes] [247127] trunk/Source/WebCore
Title: [247127] trunk/Source/WebCore
Revision 247127
Author rmoris...@apple.com
Date 2019-07-03 18:15:38 -0700 (Wed, 03 Jul 2019)
Log Message
[WHLSL] Remove the phase resolveCallsInFunctions
https://bugs.webkit.org/show_bug.cgi?id=199474
Reviewed by Myles C. Maxfield.
This pass only stores into each property access and call _expression_ vectors of all the functions it might be calling, for use by the Checker afterwards.
But the checker is perfectly able to compute a pointer to these vectors by itself.
So by removing this pass, we gain the following:
- One less pass over the AST
- No need to copy these vectors (which can be large for heavily overloaded functions, of which there are quite a few in the stdlib)
- No need to have these vectors in the expressions, saving 24 bytes per CallExpression and 72 bytes per PropertyAccessExpression
- No need to allocate and then destroy these vectors.
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h:
(WebCore::WHLSL::AST::CallExpression::castReturnType):
* Modules/webgpu/WHLSL/AST/WHLSLPropertyAccessExpression.h:
* Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp:
(WebCore::WHLSL::AutoInitialize::visit):
* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
(WebCore::WHLSL::resolveFunction):
(WebCore::WHLSL::Checker::finishVisiting):
(WebCore::WHLSL::Checker::visit):
* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
(WebCore::WHLSL::NameResolver::NameResolver):
(WebCore::WHLSL::NameResolver::visit):
* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
(WebCore::WHLSL::prepareShared):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLPropertyAccessExpression.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPrepare.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (247126 => 247127)
--- trunk/Source/WebCore/ChangeLog 2019-07-04 01:13:08 UTC (rev 247126)
+++ trunk/Source/WebCore/ChangeLog 2019-07-04 01:15:38 UTC (rev 247127)
@@ -1,5 +1,38 @@
2019-07-03 Robin Morisset
+[WHLSL] Remove the phase resolveCallsInFunctions
+https://bugs.webkit.org/show_bug.cgi?id=199474
+
+Reviewed by Myles C. Maxfield.
+
+This pass only stores into each property access and call _expression_ vectors of all the functions it might be calling, for use by the Checker afterwards.
+But the checker is perfectly able to compute a pointer to these vectors by itself.
+So by removing this pass, we gain the following:
+- One less pass over the AST
+- No need to copy these vectors (which can be large for heavily overloaded functions, of which there are quite a few in the stdlib)
+- No need to have these vectors in the expressions, saving 24 bytes per CallExpression and 72 bytes per PropertyAccessExpression
+- No need to allocate and then destroy these vectors.
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h:
+(WebCore::WHLSL::AST::CallExpression::castReturnType):
+* Modules/webgpu/WHLSL/AST/WHLSLPropertyAccessExpression.h:
+* Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp:
+(WebCore::WHLSL::AutoInitialize::visit):
+* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
+(WebCore::WHLSL::resolveFunction):
+(WebCore::WHLSL::Checker::finishVisiting):
+(WebCore::WHLSL::Checker::visit):
+* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
+(WebCore::WHLSL::NameResolver::NameResolver):
+(WebCore::WHLSL::NameResolver::visit):
+* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
+* Modules/webgpu/WHLSL/WHLSLPrepare.cpp:
+(WebCore::WHLSL::prepareShared):
+
+2019-07-03 Robin Morisset
+
[WHLSL] Make the destructor of VariableDeclaration non-virtual
https://bugs.webkit.org/show_bug.cgi?id=199460
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h (247126 => 247127)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h 2019-07-04 01:13:08 UTC (rev 247126)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLCallExpression.h 2019-07-04 01:15:38 UTC (rev 247127)
@@ -67,13 +67,6 @@
bool isCast() { return m_castReturnType; }
NamedType* castReturnType() { return m_castReturnType; }
-bool hasOverloads() const { return static_cast(m_overloads); }
-Optional, 1>>& overloads() { return m_overloads; }
-void setOverloads(const Vector, 1>& overloads)
-{
-ASSERT(!hasOverloads());
-m_overloads = overloads;
-
[webkit-changes] [247124] trunk/Source/WebCore
Title: [247124] trunk/Source/WebCore
Revision 247124
Author rmoris...@apple.com
Date 2019-07-03 18:06:35 -0700 (Wed, 03 Jul 2019)
Log Message
[WHLSL] Make the destructor of VariableDeclaration non-virtual
https://bugs.webkit.org/show_bug.cgi?id=199460
Reviewed by Myles C. Maxfield.
Three steps:
- Remove WHLSL::AST::Value, inlining it into its children (it is trivial, it just has one field m_origin with a getter and nothing else)
- Mark WHLSL::AST::VariableDeclaration final
- Now that it inherits from nothing and nothing can inherit from it, there is no reason for it to have any virtual method, including its destructor.
This not only saves 8 bytes from every variable declaration (for the virtual table pointer), it also should make destructing the AST at the end of compilation a bit faster by removing the virtual destructor call.
No new tests as there is no intended functional change.
* Modules/webgpu/WHLSL/AST/WHLSLAST.h:
* Modules/webgpu/WHLSL/AST/WHLSLExpression.h:
(WebCore::WHLSL::AST::_expression_::_expression_):
(WebCore::WHLSL::AST::_expression_::origin const):
* Modules/webgpu/WHLSL/AST/WHLSLStatement.h:
(WebCore::WHLSL::AST::Statement::Statement):
(WebCore::WHLSL::AST::Statement::origin const):
* Modules/webgpu/WHLSL/AST/WHLSLValue.h: Removed.
* Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h:
* Modules/webgpu/WHLSL/WHLSLParser.h:
* WebCore.xcodeproj/project.pbxproj:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLExpression.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStatement.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h
trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj
Removed Paths
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLValue.h
Diff
Modified: trunk/Source/WebCore/ChangeLog (247123 => 247124)
--- trunk/Source/WebCore/ChangeLog 2019-07-04 00:58:43 UTC (rev 247123)
+++ trunk/Source/WebCore/ChangeLog 2019-07-04 01:06:35 UTC (rev 247124)
@@ -1,3 +1,31 @@
+2019-07-03 Robin Morisset
+
+[WHLSL] Make the destructor of VariableDeclaration non-virtual
+https://bugs.webkit.org/show_bug.cgi?id=199460
+
+Reviewed by Myles C. Maxfield.
+
+Three steps:
+- Remove WHLSL::AST::Value, inlining it into its children (it is trivial, it just has one field m_origin with a getter and nothing else)
+- Mark WHLSL::AST::VariableDeclaration final
+- Now that it inherits from nothing and nothing can inherit from it, there is no reason for it to have any virtual method, including its destructor.
+
+This not only saves 8 bytes from every variable declaration (for the virtual table pointer), it also should make destructing the AST at the end of compilation a bit faster by removing the virtual destructor call.
+
+No new tests as there is no intended functional change.
+
+* Modules/webgpu/WHLSL/AST/WHLSLAST.h:
+* Modules/webgpu/WHLSL/AST/WHLSLExpression.h:
+(WebCore::WHLSL::AST::_expression_::_expression_):
+(WebCore::WHLSL::AST::_expression_::origin const):
+* Modules/webgpu/WHLSL/AST/WHLSLStatement.h:
+(WebCore::WHLSL::AST::Statement::Statement):
+(WebCore::WHLSL::AST::Statement::origin const):
+* Modules/webgpu/WHLSL/AST/WHLSLValue.h: Removed.
+* Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h:
+* Modules/webgpu/WHLSL/WHLSLParser.h:
+* WebCore.xcodeproj/project.pbxproj:
+
2019-07-03 Sihui Liu
Only allow fetching and removing session credentials from WebsiteDataStore
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h (247123 => 247124)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h 2019-07-04 00:58:43 UTC (rev 247123)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h 2019-07-04 01:06:35 UTC (rev 247124)
@@ -98,7 +98,6 @@
#include "WHLSLUnnamedType.h"
#include "WHLSLUnsignedIntegerLiteral.h"
#include "WHLSLUnsignedIntegerLiteralType.h"
-#include "WHLSLValue.h"
#include "WHLSLVariableDeclaration.h"
#include "WHLSLVariableDeclarationsStatement.h"
#include "WHLSLVariableReference.h"
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLExpression.h (247123 => 247124)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLExpression.h 2019-07-04 00:58:43 UTC (rev 247123)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLExpression.h 2019-07-04 01:06:35 UTC (rev 247124)
@@ -30,7 +30,6 @@
#include "WHLSLAddressSpace.h"
#include "WHLSLLexer.h"
#include "WHLSLUnnamedType.h"
-#include "WHLSLValue.h"
#include
#include
@@ -40,11 +39,10 @@
namespace AST {
-class _expression_ : public Value {
-using Base = Value;
+class _expression_ {
public:
_expression_(Lexer::Token&& origin)
-: Base(WTFMove(origin))
+:
[webkit-changes] [247110] trunk/Source/WebCore
Title: [247110] trunk/Source/WebCore Revision 247110 Author rmoris...@apple.com Date 2019-07-03 15:11:36 -0700 (Wed, 03 Jul 2019) Log Message [WHLSL] "Semantic" should be held by a unique_ptr, not an Optional https://bugs.webkit.org/show_bug.cgi?id=199462 Reviewed by Myles C. Maxfield. Most StructureElement, FunctionDeclaration and (especially) VariableDeclaration don't have a 'Semantic' field. Using an Optional to represent this is a major memory waste, as Semantic is 56 bytes, so Optional is 64 bytes! Putting one level of indirection through a unique_ptr thus saves 56 bytes for each VariableDeclaration (and FunctionDeclaration and StructureElement) that does not have a Semantic, at the low cost of one pointer dereference when accessing the field for those that have one. This patch also reorders the fields of FunctionDefinition to save another 8 bytes. No new tests as there is no intended functional change. * Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h: (WebCore::WHLSL::AST::FunctionDeclaration::FunctionDeclaration): (WebCore::WHLSL::AST::FunctionDeclaration::semantic): * Modules/webgpu/WHLSL/AST/WHLSLReadModifyWriteExpression.h: (WebCore::WHLSL::AST::ReadModifyWriteExpression::ReadModifyWriteExpression): * Modules/webgpu/WHLSL/AST/WHLSLStructureElement.h: (WebCore::WHLSL::AST::StructureElement::StructureElement): (WebCore::WHLSL::AST::StructureElement::semantic): * Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h: (WebCore::WHLSL::AST::VariableDeclaration::VariableDeclaration): (WebCore::WHLSL::AST::VariableDeclaration::semantic): * Modules/webgpu/WHLSL/WHLSLChecker.cpp: (WebCore::WHLSL::resolveWithOperatorAnderIndexer): (WebCore::WHLSL::resolveWithOperatorLength): (WebCore::WHLSL::resolveWithReferenceComparator): * Modules/webgpu/WHLSL/WHLSLGatherEntryPointItems.cpp: (WebCore::WHLSL::Gatherer::visit): (WebCore::WHLSL::gatherEntryPointItems): * Modules/webgpu/WHLSL/WHLSLParser.cpp: (WebCore::WHLSL::Parser::parseSemantic): * Modules/webgpu/WHLSL/WHLSLParser.h: * Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp: (WebCore::WHLSL::preserveVariableLifetimes): * Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp: (WebCore::WHLSL::wrapAnderCallArgument): (WebCore::WHLSL::modify): (WebCore::WHLSL::PropertyResolver::visit): * Modules/webgpu/WHLSL/WHLSLSynthesizeArrayOperatorLength.cpp: (WebCore::WHLSL::synthesizeArrayOperatorLength): * Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.cpp: (WebCore::WHLSL::synthesizeConstructors): * Modules/webgpu/WHLSL/WHLSLSynthesizeEnumerationFunctions.cpp: (WebCore::WHLSL::synthesizeEnumerationFunctions): * Modules/webgpu/WHLSL/WHLSLSynthesizeStructureAccessors.cpp: (WebCore::WHLSL::synthesizeStructureAccessors): Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReadModifyWriteExpression.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStructureElement.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLGatherEntryPointItems.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeArrayOperatorLength.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeEnumerationFunctions.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeStructureAccessors.cpp Diff Modified: trunk/Source/WebCore/ChangeLog (247109 => 247110) --- trunk/Source/WebCore/ChangeLog 2019-07-03 21:59:07 UTC (rev 247109) +++ trunk/Source/WebCore/ChangeLog 2019-07-03 22:11:36 UTC (rev 247110) @@ -1,5 +1,57 @@ 2019-07-03 Robin Morisset +[WHLSL] "Semantic" should be held by a unique_ptr, not an Optional +https://bugs.webkit.org/show_bug.cgi?id=199462 + +Reviewed by Myles C. Maxfield. + +Most StructureElement, FunctionDeclaration and (especially) VariableDeclaration don't have a 'Semantic' field. +Using an Optional to represent this is a major memory waste, as Semantic is 56 bytes, so Optional is 64 bytes! +Putting one level of indirection through a unique_ptr thus saves 56 bytes for each VariableDeclaration (and FunctionDeclaration and StructureElement) that does not have a Semantic, +at the low cost of one pointer dereference when accessing the field for those that have one. + +This patch also reorders the fields of FunctionDefinition to save another 8 bytes. + +No new tests as there is no intended functional change. + +* Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h: +
[webkit-changes] [247105] trunk/Source/WebCore
Title: [247105] trunk/Source/WebCore Revision 247105 Author rmoris...@apple.com Date 2019-07-03 14:20:04 -0700 (Wed, 03 Jul 2019) Log Message [WHLSL] WHLSL::AST::Node is useless https://bugs.webkit.org/show_bug.cgi?id=199391 Reviewed by Dean Jackson. It has no member, no non-trivial method, and we never access an AST node completely generically. So WHLSL::AST::Node can be removed, as a first step towards removing the virtual table pointer from most AST nodes (and avoiding a virtual destructor call at the end of the compiler). No new test because there is no functional change. * Modules/webgpu/WHLSL/AST/WHLSLAST.h: * Modules/webgpu/WHLSL/AST/WHLSLBaseFunctionAttribute.h: * Modules/webgpu/WHLSL/AST/WHLSLBaseSemantic.h: * Modules/webgpu/WHLSL/AST/WHLSLEnumerationMember.h: * Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h: * Modules/webgpu/WHLSL/AST/WHLSLNamedType.h: * Modules/webgpu/WHLSL/AST/WHLSLReplaceWith.h: Renamed from Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNode.h. (WebCore::WHLSL::AST::replaceWith): * Modules/webgpu/WHLSL/AST/WHLSLStructureElement.h: * Modules/webgpu/WHLSL/AST/WHLSLType.h: * Modules/webgpu/WHLSL/AST/WHLSLTypeDefinition.h: * Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h: * Modules/webgpu/WHLSL/AST/WHLSLValue.h: * Modules/webgpu/WHLSL/WHLSLNameResolver.cpp: * Modules/webgpu/WHLSL/WHLSLParser.h: * Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp: * Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp: * WebCore.xcodeproj/project.pbxproj: Modified Paths trunk/Source/WebCore/ChangeLog trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBaseFunctionAttribute.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLBaseSemantic.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLEnumerationMember.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNamedType.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLStructureElement.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLType.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLTypeDefinition.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLValue.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.h trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp trunk/Source/WebCore/WebCore.xcodeproj/project.pbxproj Added Paths trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReplaceWith.h Removed Paths trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNode.h Diff Modified: trunk/Source/WebCore/ChangeLog (247104 => 247105) --- trunk/Source/WebCore/ChangeLog 2019-07-03 21:16:43 UTC (rev 247104) +++ trunk/Source/WebCore/ChangeLog 2019-07-03 21:20:04 UTC (rev 247105) @@ -1,3 +1,34 @@ +2019-07-03 Robin Morisset + +[WHLSL] WHLSL::AST::Node is useless +https://bugs.webkit.org/show_bug.cgi?id=199391 + +Reviewed by Dean Jackson. + +It has no member, no non-trivial method, and we never access an AST node completely generically. +So WHLSL::AST::Node can be removed, as a first step towards removing the virtual table pointer from most AST nodes (and avoiding a virtual destructor call at the end of the compiler). + +No new test because there is no functional change. + +* Modules/webgpu/WHLSL/AST/WHLSLAST.h: +* Modules/webgpu/WHLSL/AST/WHLSLBaseFunctionAttribute.h: +* Modules/webgpu/WHLSL/AST/WHLSLBaseSemantic.h: +* Modules/webgpu/WHLSL/AST/WHLSLEnumerationMember.h: +* Modules/webgpu/WHLSL/AST/WHLSLFunctionDeclaration.h: +* Modules/webgpu/WHLSL/AST/WHLSLNamedType.h: +* Modules/webgpu/WHLSL/AST/WHLSLReplaceWith.h: Renamed from Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLNode.h. +(WebCore::WHLSL::AST::replaceWith): +* Modules/webgpu/WHLSL/AST/WHLSLStructureElement.h: +* Modules/webgpu/WHLSL/AST/WHLSLType.h: +* Modules/webgpu/WHLSL/AST/WHLSLTypeDefinition.h: +* Modules/webgpu/WHLSL/AST/WHLSLUnnamedType.h: +* Modules/webgpu/WHLSL/AST/WHLSLValue.h: +* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp: +* Modules/webgpu/WHLSL/WHLSLParser.h: +* Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp: +* Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp: +* WebCore.xcodeproj/project.pbxproj: + 2019-07-03 Youenn Fablet Strengthen updating/removing of registrations from the database Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h (247104 => 247105) --- trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h 2019-07-03 21:16:43 UTC (rev 247104) +++ trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLAST.h 2019-07-03 21:20:04 UTC (rev 247105) @@ -69,7 +69,6 @@
[webkit-changes] [247062] trunk/Source
Title: [247062] trunk/Source
Revision 247062
Author rmoris...@apple.com
Date 2019-07-02 11:13:17 -0700 (Tue, 02 Jul 2019)
Log Message
[WHLSL] the initializer in VariableDeclaration should be a std::unique_ptr, not Optional>
https://bugs.webkit.org/show_bug.cgi?id=199389
Reviewed by Sam Weinig.
Source/WebCore:
Optional> is not only semantically weird (UniqueRef is basically a unique_ptr that promises not to be null), but also inefficient, wasting 8 bytes for the boolean in Optional.
It is a pattern that appears throughout the AST. In this patch I start by removing it in a fairly simple spot: the initializer for VariableDeclaration.
No test because there is no intended functional change.
* Modules/webgpu/WHLSL/AST/WHLSLReadModifyWriteExpression.h:
(WebCore::WHLSL::AST::ReadModifyWriteExpression::ReadModifyWriteExpression):
* Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h:
(WebCore::WHLSL::AST::VariableDeclaration::VariableDeclaration):
(WebCore::WHLSL::AST::VariableDeclaration::initializer):
(WebCore::WHLSL::AST::VariableDeclaration::takeInitializer):
(WebCore::WHLSL::AST::VariableDeclaration::setInitializer):
* Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp:
(WebCore::WHLSL::AutoInitialize::visit):
* Modules/webgpu/WHLSL/WHLSLChecker.cpp:
(WebCore::WHLSL::resolveWithOperatorAnderIndexer):
(WebCore::WHLSL::resolveWithOperatorLength):
(WebCore::WHLSL::resolveWithReferenceComparator):
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseParameter):
(WebCore::WHLSL::Parser::parseVariableDeclaration):
* Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp:
* Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp:
(WebCore::WHLSL::wrapAnderCallArgument):
(WebCore::WHLSL::modify):
(WebCore::WHLSL::PropertyResolver::visit):
* Modules/webgpu/WHLSL/WHLSLSynthesizeArrayOperatorLength.cpp:
(WebCore::WHLSL::synthesizeArrayOperatorLength):
* Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.cpp:
(WebCore::WHLSL::synthesizeConstructors):
* Modules/webgpu/WHLSL/WHLSLSynthesizeEnumerationFunctions.cpp:
(WebCore::WHLSL::synthesizeEnumerationFunctions):
* Modules/webgpu/WHLSL/WHLSLSynthesizeStructureAccessors.cpp:
(WebCore::WHLSL::synthesizeStructureAccessors):
Source/WTF:
* wtf/UniqueRef.h:
(WTF::UniqueRef::moveToUniquePtr): Added.
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/UniqueRef.h
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLReadModifyWriteExpression.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/AST/WHLSLVariableDeclaration.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLAutoInitializeVariables.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLChecker.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPreserveVariableLifetimes.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLPropertyResolver.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeArrayOperatorLength.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeConstructors.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeEnumerationFunctions.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLSynthesizeStructureAccessors.cpp
Diff
Modified: trunk/Source/WTF/ChangeLog (247061 => 247062)
--- trunk/Source/WTF/ChangeLog 2019-07-02 18:12:59 UTC (rev 247061)
+++ trunk/Source/WTF/ChangeLog 2019-07-02 18:13:17 UTC (rev 247062)
@@ -1,3 +1,13 @@
+2019-07-02 Robin Morisset
+
+[WHLSL] the initializer in VariableDeclaration should be a std::unique_ptr, not Optional>
+https://bugs.webkit.org/show_bug.cgi?id=199389
+
+Reviewed by Sam Weinig.
+
+* wtf/UniqueRef.h:
+(WTF::UniqueRef::moveToUniquePtr): Added.
+
2019-07-02 Keith Miller
PACCage should first cage leaving PAC bits intact then authenticate
Modified: trunk/Source/WTF/wtf/UniqueRef.h (247061 => 247062)
--- trunk/Source/WTF/wtf/UniqueRef.h 2019-07-02 18:12:59 UTC (rev 247061)
+++ trunk/Source/WTF/wtf/UniqueRef.h 2019-07-02 18:13:17 UTC (rev 247062)
@@ -60,6 +60,8 @@
operator T&() { ASSERT(m_ref); return *m_ref; }
operator const T&() const { ASSERT(m_ref); return *m_ref; }
+std::unique_ptr moveToUniquePtr() { return WTFMove(m_ref); }
+
private:
template friend UniqueRef makeUniqueRef(Args&&...);
template friend class UniqueRef;
Modified: trunk/Source/WebCore/ChangeLog (247061 => 247062)
--- trunk/Source/WebCore/ChangeLog 2019-07-02 18:12:59 UTC (rev 247061)
+++ trunk/Source/WebCore/ChangeLog 2019-07-02 18:13:17 UTC (rev 247062)
@@ -1,3 +1,45 @@
+2019-07-02 Robin Morisset
+
+[WHLSL] the initializer in VariableDeclaration should be a std::unique_ptr, not Optional>
+https://bugs.webkit.org/show_bug.cgi?id=199389
+
+Reviewed by Sam Weinig.
+
+Optional> is not only semantically weird (UniqueRef is basically a unique_ptr that promises not to be null), but also inefficient, wasting 8 bytes for the boolean in Optional.
+
[webkit-changes] [246944] trunk/Tools
Title: [246944] trunk/Tools
Revision 246944
Author rmoris...@apple.com
Date 2019-06-28 15:48:13 -0700 (Fri, 28 Jun 2019)
Log Message
Adding myself as a reviewer in contributors.json.
Modified Paths
trunk/Tools/ChangeLog
trunk/Tools/Scripts/webkitpy/common/config/contributors.json
Diff
Modified: trunk/Tools/ChangeLog (246943 => 246944)
--- trunk/Tools/ChangeLog 2019-06-28 22:27:58 UTC (rev 246943)
+++ trunk/Tools/ChangeLog 2019-06-28 22:48:13 UTC (rev 246944)
@@ -1,3 +1,11 @@
+2019-06-28 Robin Morisset
+
+Adding myself as a reviewer to contributors.json.
+
+Unreviewed.
+
+* Scripts/webkitpy/common/config/contributors.json:
+
2019-06-28 Jer Noble
Add new -[WKWebView _closeAllMediaPresentations] SPI
Modified: trunk/Tools/Scripts/webkitpy/common/config/contributors.json (246943 => 246944)
--- trunk/Tools/Scripts/webkitpy/common/config/contributors.json 2019-06-28 22:27:58 UTC (rev 246943)
+++ trunk/Tools/Scripts/webkitpy/common/config/contributors.json 2019-06-28 22:48:13 UTC (rev 246944)
@@ -4627,7 +4627,7 @@
"nicks" : [
"rmorisset"
],
- "status" : "committer"
+ "status" : "reviewer"
},
"Roger Fong" : {
"emails" : [
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [246524] trunk/Source/WebCore
Title: [246524] trunk/Source/WebCore
Revision 246524
Author rmoris...@apple.com
Date 2019-06-17 17:06:17 -0700 (Mon, 17 Jun 2019)
Log Message
[WHLSL] The name resolver does not deal with nativeFunctionDeclaration
https://bugs.webkit.org/show_bug.cgi?id=198306
Reviewed by Saam Barati.
We currently have a crash in the nameResolver when trying to use the full standard library.
What is happening is that because we don't specify anything to do to nativeFunctionDeclarations, names in their parameters
are added to the global environment. And so as soon as we have two such parameters with the same name, the name resolver fails.
Tested by adding two native functions that share a parameter name to the standard library.
* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
(WebCore::WHLSL::NameResolver::visit):
* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibrary.txt
Diff
Modified: trunk/Source/WebCore/ChangeLog (246523 => 246524)
--- trunk/Source/WebCore/ChangeLog 2019-06-17 23:42:41 UTC (rev 246523)
+++ trunk/Source/WebCore/ChangeLog 2019-06-18 00:06:17 UTC (rev 246524)
@@ -1,5 +1,22 @@
2019-06-17 Robin Morisset
+[WHLSL] The name resolver does not deal with nativeFunctionDeclaration
+https://bugs.webkit.org/show_bug.cgi?id=198306
+
+Reviewed by Saam Barati.
+
+We currently have a crash in the nameResolver when trying to use the full standard library.
+What is happening is that because we don't specify anything to do to nativeFunctionDeclarations, names in their parameters
+are added to the global environment. And so as soon as we have two such parameters with the same name, the name resolver fails.
+
+Tested by adding two native functions that share a parameter name to the standard library.
+
+* Modules/webgpu/WHLSL/WHLSLNameResolver.cpp:
+(WebCore::WHLSL::NameResolver::visit):
+* Modules/webgpu/WHLSL/WHLSLNameResolver.h:
+
+2019-06-17 Robin Morisset
+
[WHLSL] Remove backtracking from parseAttributeBlock
https://bugs.webkit.org/show_bug.cgi?id=198934
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp (246523 => 246524)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp 2019-06-17 23:42:41 UTC (rev 246523)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.cpp 2019-06-18 00:06:17 UTC (rev 246524)
@@ -94,6 +94,16 @@
newNameResolver.checkErrorAndVisit(functionDefinition.block());
}
+void NameResolver::visit(AST::NativeFunctionDeclaration& nativeFunctionDeclaration)
+{
+NameContext newNameContext(_nameContext);
+NameResolver newNameResolver(newNameContext);
+newNameResolver.setCurrentFunctionDefinition(m_currentFunction);
+checkErrorAndVisit(nativeFunctionDeclaration.type());
+for (auto& parameter : nativeFunctionDeclaration.parameters())
+newNameResolver.checkErrorAndVisit(parameter);
+}
+
void NameResolver::visit(AST::Block& block)
{
NameContext nameContext(_nameContext);
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h (246523 => 246524)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h 2019-06-17 23:42:41 UTC (rev 246523)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLNameResolver.h 2019-06-18 00:06:17 UTC (rev 246524)
@@ -43,8 +43,6 @@
virtual ~NameResolver() = default;
-void visit(AST::FunctionDefinition&) override;
-
void setCurrentFunctionDefinition(AST::FunctionDefinition* functionDefinition)
{
m_currentFunction = functionDefinition;
@@ -51,6 +49,8 @@
}
private:
+void visit(AST::FunctionDefinition&) override;
+void visit(AST::NativeFunctionDeclaration&) override;
void visit(AST::TypeReference&) override;
void visit(AST::Block&) override;
void visit(AST::IfStatement&) override;
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibrary.txt (246523 => 246524)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibrary.txt 2019-06-17 23:42:41 UTC (rev 246523)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLStandardLibrary.txt 2019-06-18 00:06:17 UTC (rev 246524)
@@ -625,4 +625,7 @@
return result;
}
+native ushort Sample(Texture1D, sampler, float location);
+native ushort Sample(Texture1D, sampler, float location, int offset);
+
// FIXME: https://bugs.webkit.org/show_bug.cgi?id=192890 Insert the rest of the standard library once the parser is fast enough
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [246520] trunk/Source/WebCore
Title: [246520] trunk/Source/WebCore
Revision 246520
Author rmoris...@apple.com
Date 2019-06-17 16:07:32 -0700 (Mon, 17 Jun 2019)
Log Message
[WHLSL] Remove backtracking from parseAttributeBlock
https://bugs.webkit.org/show_bug.cgi?id=198934
Reviewed by Myles C. Maxfield.
No functional change intended.
Tested by running LayoutTests/webgpu/whlsl-compute.html
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseAttributeBlock):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (246519 => 246520)
--- trunk/Source/WebCore/ChangeLog 2019-06-17 22:27:26 UTC (rev 246519)
+++ trunk/Source/WebCore/ChangeLog 2019-06-17 23:07:32 UTC (rev 246520)
@@ -1,3 +1,17 @@
+2019-06-17 Robin Morisset
+
+[WHLSL] Remove backtracking from parseAttributeBlock
+https://bugs.webkit.org/show_bug.cgi?id=198934
+
+Reviewed by Myles C. Maxfield.
+
+No functional change intended.
+
+Tested by running LayoutTests/webgpu/whlsl-compute.html
+
+* Modules/webgpu/WHLSL/WHLSLParser.cpp:
+(WebCore::WHLSL::Parser::parseAttributeBlock):
+
2019-06-17 Saam Barati
[WHLSL] Make .length work
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp (246519 => 246520)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp 2019-06-17 22:27:26 UTC (rev 246519)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp 2019-06-17 23:07:32 UTC (rev 246520)
@@ -854,19 +854,12 @@
AST::AttributeBlock result;
while (true) {
-auto numThreadsFunctionAttribute = backtrackingScope>([&]() {
-return parseNumThreadsFunctionAttribute();
-});
-if (numThreadsFunctionAttribute) {
-result.append(WTFMove(*numThreadsFunctionAttribute));
-continue;
-}
-
-break;
+if (tryType(Lexer::Token::Type::RightSquareBracket))
+break;
+PARSE(numThreadsFunctionAttribute, NumThreadsFunctionAttribute);
+result.append(WTFMove(*numThreadsFunctionAttribute));
}
-CONSUME_TYPE(rightSquareBracket, RightSquareBracket);
-
return WTFMove(result);
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [245312] trunk/Source/WebCore
Title: [245312] trunk/Source/WebCore
Revision 245312
Author rmoris...@apple.com
Date 2019-05-14 14:49:54 -0700 (Tue, 14 May 2019)
Log Message
[WHLSL] parseEffectfulSuffix() is never called
https://bugs.webkit.org/show_bug.cgi?id=195864
Reviewed by Myles C. Maxfield.
The fix is trivial: when parseEffectfulPrefix does not see a ++ or --, it must call parseEffectfulSuffix.
No test yet, as it is not testable until the property resolver is finished.
It will be tested with the rest of the compiler, when we port the testsuite from the js implementation (it already covers this case).
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseEffectfulPrefix):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (245311 => 245312)
--- trunk/Source/WebCore/ChangeLog 2019-05-14 21:38:12 UTC (rev 245311)
+++ trunk/Source/WebCore/ChangeLog 2019-05-14 21:49:54 UTC (rev 245312)
@@ -1,5 +1,21 @@
2019-05-14 Robin Morisset
+[WHLSL] parseEffectfulSuffix() is never called
+https://bugs.webkit.org/show_bug.cgi?id=195864
+
+
+Reviewed by Myles C. Maxfield.
+
+The fix is trivial: when parseEffectfulPrefix does not see a ++ or --, it must call parseEffectfulSuffix.
+
+No test yet, as it is not testable until the property resolver is finished.
+It will be tested with the rest of the compiler, when we port the testsuite from the js implementation (it already covers this case).
+
+* Modules/webgpu/WHLSL/WHLSLParser.cpp:
+(WebCore::WHLSL::Parser::parseEffectfulPrefix):
+
+2019-05-14 Robin Morisset
+
[WHLSL] parseEffectfulAssignment should not call parseCallExpression directly
https://bugs.webkit.org/show_bug.cgi?id=197890
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp (245311 => 245312)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp 2019-05-14 21:38:12 UTC (rev 245311)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp 2019-05-14 21:49:54 UTC (rev 245312)
@@ -1810,7 +1810,7 @@
{
auto prefix = consumeTypes({ Lexer::Token::Type::PlusPlus, Lexer::Token::Type::MinusMinus });
if (!prefix)
-return Unexpected(prefix.error());
+return parseEffectfulSuffix();
auto previous = parsePossiblePrefix();
if (!previous)
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [245302] trunk/Source/WebCore
Title: [245302] trunk/Source/WebCore
Revision 245302
Author rmoris...@apple.com
Date 2019-05-14 13:35:32 -0700 (Tue, 14 May 2019)
Log Message
[WHLSL] parseEffectfulAssignment should not call parseCallExpression directly
https://bugs.webkit.org/show_bug.cgi?id=197890
Reviewed by Myles Maxfield.
callExpression already appears in effSuffix which is in effPrefix which is in effAssignment, so having it directly in effAssignment as well is useless (and ambiguous).
I've already fixed the grammar (https://github.com/gpuweb/WHLSL/commit/a07005f4d692fe3370618dca5db218992b362049), the grammar was always good, this patch is fixing the parser.
* Modules/webgpu/WHLSL/WHLSLParser.cpp:
(WebCore::WHLSL::Parser::parseEffectfulAssignment):
Modified Paths
trunk/Source/WebCore/ChangeLog
trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp
Diff
Modified: trunk/Source/WebCore/ChangeLog (245301 => 245302)
--- trunk/Source/WebCore/ChangeLog 2019-05-14 20:30:38 UTC (rev 245301)
+++ trunk/Source/WebCore/ChangeLog 2019-05-14 20:35:32 UTC (rev 245302)
@@ -1,3 +1,16 @@
+2019-05-14 Robin Morisset
+
+[WHLSL] parseEffectfulAssignment should not call parseCallExpression directly
+https://bugs.webkit.org/show_bug.cgi?id=197890
+
+Reviewed by Myles Maxfield.
+
+callExpression already appears in effSuffix which is in effPrefix which is in effAssignment, so having it directly in effAssignment as well is useless (and ambiguous).
+I've already fixed the grammar (https://github.com/gpuweb/WHLSL/commit/a07005f4d692fe3370618dca5db218992b362049), the grammar was always good, this patch is fixing the parser.
+
+* Modules/webgpu/WHLSL/WHLSLParser.cpp:
+(WebCore::WHLSL::Parser::parseEffectfulAssignment):
+
2019-05-14 Ross Kirsling
Unreviewed restoration of non-unified build.
Modified: trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp (245301 => 245302)
--- trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp 2019-05-14 20:30:38 UTC (rev 245301)
+++ trunk/Source/WebCore/Modules/webgpu/WHLSL/WHLSLParser.cpp 2019-05-14 20:35:32 UTC (rev 245302)
@@ -1803,12 +1803,6 @@
if (assignment)
return assignment;
-assignment = backtrackingScope, Error>>([&]() {
-return parseCallExpression();
-});
-if (assignment)
-return assignment;
-
return Unexpected(assignment.error());
}
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [245271] trunk/Source/WTF
Title: [245271] trunk/Source/WTF
Revision 245271
Author rmoris...@apple.com
Date 2019-05-13 20:38:13 -0700 (Mon, 13 May 2019)
Log Message
IndexSet::isEmpty should use BitVector::isEmpty() instead of size()
https://bugs.webkit.org/show_bug.cgi?id=197857
Reviewed by Darin Adler.
* wtf/IndexSet.h:
(WTF::IndexSet::isEmpty const):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/IndexSet.h
Diff
Modified: trunk/Source/WTF/ChangeLog (245270 => 245271)
--- trunk/Source/WTF/ChangeLog 2019-05-14 02:34:28 UTC (rev 245270)
+++ trunk/Source/WTF/ChangeLog 2019-05-14 03:38:13 UTC (rev 245271)
@@ -1,3 +1,13 @@
+2019-05-13 Robin Morisset
+
+IndexSet::isEmpty should use BitVector::isEmpty() instead of size()
+https://bugs.webkit.org/show_bug.cgi?id=197857
+
+Reviewed by Darin Adler.
+
+* wtf/IndexSet.h:
+(WTF::IndexSet::isEmpty const):
+
2019-05-13 Youenn Fablet
[Mac] Use realpath for dlopen_preflight
Modified: trunk/Source/WTF/wtf/IndexSet.h (245270 => 245271)
--- trunk/Source/WTF/wtf/IndexSet.h 2019-05-14 02:34:28 UTC (rev 245270)
+++ trunk/Source/WTF/wtf/IndexSet.h 2019-05-14 03:38:13 UTC (rev 245271)
@@ -76,7 +76,7 @@
bool isEmpty() const
{
-return !size();
+return m_set.isEmpty();
}
template
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [245192] trunk/Source/JavaScriptCore
Title: [245192] trunk/Source/_javascript_Core
Revision 245192
Author rmoris...@apple.com
Date 2019-05-10 13:37:07 -0700 (Fri, 10 May 2019)
Log Message
testb3 failing with crash in JSC::B3::BasicBlock::appendNonTerminal
https://bugs.webkit.org/show_bug.cgi?id=197756
Reviewed by Saam Barati.
When I added https://bugs.webkit.org/show_bug.cgi?id=197265 I assumed that which block is the root does not change in the middle of strength reduction.
But specializeSelect can use splitForward, which uses a new block for the first half of the given block.
So if the block being split is the root block I must update m_root and erase the m_valueInConstant cache.
Erasing the cache cannot cause wrong results: at most it can make us miss some optimization opportunities in this iteration of the fixpoint.
* b3/B3ReduceStrength.cpp:
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/B3ReduceStrength.cpp
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (245191 => 245192)
--- trunk/Source/_javascript_Core/ChangeLog 2019-05-10 20:30:05 UTC (rev 245191)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-05-10 20:37:07 UTC (rev 245192)
@@ -1,3 +1,18 @@
+2019-05-10 Robin Morisset
+
+testb3 failing with crash in JSC::B3::BasicBlock::appendNonTerminal
+https://bugs.webkit.org/show_bug.cgi?id=197756
+
+
+Reviewed by Saam Barati.
+
+When I added https://bugs.webkit.org/show_bug.cgi?id=197265 I assumed that which block is the root does not change in the middle of strength reduction.
+But specializeSelect can use splitForward, which uses a new block for the first half of the given block.
+So if the block being split is the root block I must update m_root and erase the m_valueInConstant cache.
+Erasing the cache cannot cause wrong results: at most it can make us miss some optimization opportunities in this iteration of the fixpoint.
+
+* b3/B3ReduceStrength.cpp:
+
2019-05-09 Keith Miller
Fix crashes related to pointer authentication for primitive gigacage
Modified: trunk/Source/_javascript_Core/b3/B3ReduceStrength.cpp (245191 => 245192)
--- trunk/Source/_javascript_Core/b3/B3ReduceStrength.cpp 2019-05-10 20:30:05 UTC (rev 245191)
+++ trunk/Source/_javascript_Core/b3/B3ReduceStrength.cpp 2019-05-10 20:37:07 UTC (rev 245192)
@@ -2162,6 +2162,7 @@
m_valueForConstant.add(key, m_value);
else {
Value* constInRoot = m_proc.clone(m_value);
+ASSERT(m_root && m_root->size() >= 1);
m_root->appendNonTerminal(constInRoot);
m_valueForConstant.add(key, constInRoot);
m_value->replaceWithIdentity(constInRoot);
@@ -2224,8 +2225,11 @@
// This mutates startIndex to account for the fact that m_block got the front of it
// chopped off.
-BasicBlock* predecessor =
-m_blockInsertionSet.splitForward(m_block, m_index, _insertionSet);
+BasicBlock* predecessor = m_blockInsertionSet.splitForward(m_block, m_index, _insertionSet);
+if (m_block == m_root) {
+m_root = predecessor;
+m_valueForConstant.clear();
+}
// Splitting will commit the insertion set, which changes the exact position of the
// source. That's why we do the search after splitting.
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [245061] trunk/Source/WTF
Title: [245061] trunk/Source/WTF
Revision 245061
Author rmoris...@apple.com
Date 2019-05-08 11:18:42 -0700 (Wed, 08 May 2019)
Log Message
WTF::TimingScope should show the total duration and not just the mean
https://bugs.webkit.org/show_bug.cgi?id=197672
Reviewed by Alex Christensen.
* wtf/TimingScope.cpp:
(WTF::TimingScope::scopeDidEnd):
Modified Paths
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/TimingScope.cpp
Diff
Modified: trunk/Source/WTF/ChangeLog (245060 => 245061)
--- trunk/Source/WTF/ChangeLog 2019-05-08 17:44:47 UTC (rev 245060)
+++ trunk/Source/WTF/ChangeLog 2019-05-08 18:18:42 UTC (rev 245061)
@@ -1,3 +1,13 @@
+2019-05-08 Robin Morisset
+
+WTF::TimingScope should show the total duration and not just the mean
+https://bugs.webkit.org/show_bug.cgi?id=197672
+
+Reviewed by Alex Christensen.
+
+* wtf/TimingScope.cpp:
+(WTF::TimingScope::scopeDidEnd):
+
2019-05-07 Yusuke Suzuki
[JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
Modified: trunk/Source/WTF/wtf/TimingScope.cpp (245060 => 245061)
--- trunk/Source/WTF/wtf/TimingScope.cpp 2019-05-08 17:44:47 UTC (rev 245060)
+++ trunk/Source/WTF/wtf/TimingScope.cpp 2019-05-08 18:18:42 UTC (rev 245061)
@@ -73,7 +73,7 @@
{
const auto& data = "" MonotonicTime::now() - m_startTime);
if (!(data.callCount % m_logIterationInterval))
-WTFLogAlways("%s: %u calls, mean duration: %.6fms", m_name, data.callCount, data.meanDuration().milliseconds());
+WTFLogAlways("%s: %u calls, mean duration: %.6fms, total duration: %.6fms", m_name, data.callCount, data.meanDuration().milliseconds(), data.totalDuration.milliseconds());
}
} // namespace WebCore
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
[webkit-changes] [245035] trunk/Source/JavaScriptCore
Title: [245035] trunk/Source/_javascript_Core Revision 245035 Author rmoris...@apple.com Date 2019-05-07 14:28:38 -0700 (Tue, 07 May 2019) Log Message [B3] Constants should be hoisted to the root block until moveConstants https://bugs.webkit.org/show_bug.cgi?id=197265 Reviewed by Saam Barati. This patch does the following: - B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way - B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them - We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure. - I also took the opportunity to fix typos in comments in various parts of the code base. Here are a few numbers to justify this patch: - In JetStream2, about 27% of values at the beginning of B3 are constants - In JetStream2, about 11% of values at the end of B3 are Nops - In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller). When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression. * b3/B3Generate.cpp: (JSC::B3::generateToAir): * b3/B3MoveConstants.cpp: * b3/B3PureCSE.cpp: (JSC::B3::PureCSE::process): * b3/B3PureCSE.h: * b3/B3ReduceStrength.cpp: * bytecode/GetByIdStatus.cpp: (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): * dfg/DFGCSEPhase.cpp: * dfg/DFGOSRAvailabilityAnalysisPhase.h: * dfg/DFGOSRExit.cpp: (JSC::DFG::OSRExit::executeOSRExit): Modified Paths trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/b3/B3Generate.cpp trunk/Source/_javascript_Core/b3/B3MoveConstants.cpp trunk/Source/_javascript_Core/b3/B3PureCSE.cpp trunk/Source/_javascript_Core/b3/B3PureCSE.h trunk/Source/_javascript_Core/b3/B3ReduceStrength.cpp trunk/Source/_javascript_Core/bytecode/GetByIdStatus.cpp trunk/Source/_javascript_Core/dfg/DFGCSEPhase.cpp trunk/Source/_javascript_Core/dfg/DFGOSRAvailabilityAnalysisPhase.h trunk/Source/_javascript_Core/dfg/DFGOSRExit.cpp Diff Modified: trunk/Source/_javascript_Core/ChangeLog (245034 => 245035) --- trunk/Source/_javascript_Core/ChangeLog 2019-05-07 21:09:54 UTC (rev 245034) +++ trunk/Source/_javascript_Core/ChangeLog 2019-05-07 21:28:38 UTC (rev 245035) @@ -1,5 +1,39 @@ 2019-05-07 Robin Morisset +[B3] Constants should be hoisted to the root block until moveConstants +https://bugs.webkit.org/show_bug.cgi?id=197265 + +Reviewed by Saam Barati. + +This patch does the following: +- B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way +- B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them +- We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure. +- I also took the opportunity to fix typos in comments in various parts of the code base. + +Here are a few numbers to justify this patch: +- In JetStream2, about 27% of values at the beginning of B3 are constants +- In JetStream2, about 11% of values at the end of B3 are Nops +- In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller). + +When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression. + +* b3/B3Generate.cpp: +(JSC::B3::generateToAir): +* b3/B3MoveConstants.cpp: +* b3/B3PureCSE.cpp: +(JSC::B3::PureCSE::process): +* b3/B3PureCSE.h: +* b3/B3ReduceStrength.cpp: +* bytecode/GetByIdStatus.cpp: +(JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback): +* dfg/DFGCSEPhase.cpp: +* dfg/DFGOSRAvailabilityAnalysisPhase.h: +* dfg/DFGOSRExit.cpp: +(JSC::DFG::OSRExit::executeOSRExit): + +2019-05-07 Robin Morisset + All prototypes should call didBecomePrototype() https://bugs.webkit.org/show_bug.cgi?id=196315 Modified: trunk/Source/_javascript_Core/b3/B3Generate.cpp (245034 => 245035) --- trunk/Source/_javascript_Core/b3/B3Generate.cpp 2019-05-07 21:09:54 UTC (rev 245034) +++ trunk/Source/_javascript_Core/b3/B3Generate.cpp 2019-05-07 21:28:38 UTC (rev 245035) @@ -116,6 +116,7 @@ lowerMacrosAfterOptimizations(procedure); legalizeMemoryOffsets(procedure); moveConstants(procedure); +eliminateDeadCode(procedure); // FIXME: We should run pureCSE here to clean up some platform specific changes from the previous phases. //
[webkit-changes] [245031] trunk
Title: [245031] trunk Revision 245031 Author rmoris...@apple.com Date 2019-05-07 13:59:44 -0700 (Tue, 07 May 2019) Log Message All prototypes should call didBecomePrototype() https://bugs.webkit.org/show_bug.cgi?id=196315 Reviewed by Saam Barati. JSTests: * stress/function-prototype-indexed-accessor.js: Added. Source/_javascript_Core: Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor. I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't create structures with invalid prototypes. It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation(). Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype. * runtime/BigIntPrototype.cpp: (JSC::BigIntPrototype::finishCreation): * runtime/BooleanPrototype.cpp: (JSC::BooleanPrototype::finishCreation): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::finishCreation): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::finishCreation): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::finishCreation): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototype::finishCreation): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): * runtime/IntlPluralRulesPrototype.cpp: (JSC::IntlPluralRulesPrototype::finishCreation): * runtime/JSArrayBufferPrototype.cpp: (JSC::JSArrayBufferPrototype::finishCreation): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::finishCreation): * runtime/JSGenericTypedArrayViewPrototypeInlines.h: (JSC::JSGenericTypedArrayViewPrototype::finishCreation): * runtime/JSGlobalObject.cpp: (JSC::createConsoleProperty): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::finishCreation): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::finishCreation): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::finishCreation): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): * runtime/Structure.cpp: (JSC::Structure::isValidPrototype): (JSC::Structure::changePrototypeTransition): * runtime/Structure.h: * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): * wasm/js/WebAssemblyCompileErrorPrototype.cpp: (JSC::WebAssemblyCompileErrorPrototype::finishCreation): * wasm/js/WebAssemblyInstancePrototype.cpp: (JSC::WebAssemblyInstancePrototype::finishCreation): * wasm/js/WebAssemblyLinkErrorPrototype.cpp: (JSC::WebAssemblyLinkErrorPrototype::finishCreation): * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::WebAssemblyMemoryPrototype::finishCreation): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::WebAssemblyModulePrototype::finishCreation): * wasm/js/WebAssemblyPrototype.cpp: (JSC::WebAssemblyPrototype::finishCreation): * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation): * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::WebAssemblyTablePrototype::finishCreation): Source/WebCore: It was found by existing tests, with the new assert in JSC::Structure * bindings/js/JSWindowProxy.cpp: (WebCore::JSWindowProxy::setWindow): * bindings/scripts/CodeGeneratorJS.pm: (GeneratePrototypeDeclaration): (GenerateConstructorHelperMethods): Modified Paths trunk/JSTests/ChangeLog trunk/Source/_javascript_Core/ChangeLog trunk/Source/WebCore/ChangeLog Diff Modified: trunk/JSTests/ChangeLog (245030 => 245031) --- trunk/JSTests/ChangeLog 2019-05-07 20:46:43 UTC (rev 245030) +++ trunk/JSTests/ChangeLog 2019-05-07 20:59:44 UTC (rev 245031) @@ -1,3 +1,12 @@ +2019-05-07 Robin Morisset + +All prototypes should call didBecomePrototype() +https://bugs.webkit.org/show_bug.cgi?id=196315 + +Reviewed by Saam Barati. + +* stress/function-prototype-indexed-accessor.js: Added. + 2019-05-07 Commit Queue Unreviewed, rolling out r244978. Modified: trunk/Source/_javascript_Core/ChangeLog (245030 => 245031) --- trunk/Source/_javascript_Core/ChangeLog 2019-05-07 20:46:43 UTC (rev 245030) +++ trunk/Source/_javascript_Core/ChangeLog 2019-05-07 20:59:44 UTC (rev 245031) @@ -1,5 +1,84 @@ 2019-05-07 Robin Morisset +All prototypes should call didBecomePrototype() +https://bugs.webkit.org/show_bug.cgi?id=196315 + +Reviewed by Saam Barati. + +Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor. + +I added a check used in both
[webkit-changes] [245030] trunk/Source
Title: [245030] trunk/Source
Revision 245030
Author rmoris...@apple.com
Date 2019-05-07 13:46:43 -0700 (Tue, 07 May 2019)
Log Message
WTF::BitVector should have an isEmpty() method
https://bugs.webkit.org/show_bug.cgi?id=197637
Reviewed by Keith Miller.
Source/_javascript_Core:
Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
Source/WTF:
* wtf/BitVector.cpp:
(WTF::BitVector::isEmptySlow const):
* wtf/BitVector.h:
(WTF::BitVector::isEmpty const):
Modified Paths
trunk/Source/_javascript_Core/ChangeLog
trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp
trunk/Source/WTF/ChangeLog
trunk/Source/WTF/wtf/BitVector.cpp
trunk/Source/WTF/wtf/BitVector.h
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (245029 => 245030)
--- trunk/Source/_javascript_Core/ChangeLog 2019-05-07 20:32:04 UTC (rev 245029)
+++ trunk/Source/_javascript_Core/ChangeLog 2019-05-07 20:46:43 UTC (rev 245030)
@@ -1,3 +1,14 @@
+2019-05-07 Robin Morisset
+
+WTF::BitVector should have an isEmpty() method
+https://bugs.webkit.org/show_bug.cgi?id=197637
+
+Reviewed by Keith Miller.
+
+Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
+
+* b3/air/AirAllocateRegistersByGraphColoring.cpp:
+
2019-05-07 Commit Queue
Unreviewed, rolling out r244978.
Modified: trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp (245029 => 245030)
--- trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2019-05-07 20:32:04 UTC (rev 245029)
+++ trunk/Source/_javascript_Core/b3/air/AirAllocateRegistersByGraphColoring.cpp 2019-05-07 20:46:43 UTC (rev 245030)
@@ -324,7 +324,7 @@
void assignColors()
{
ASSERT(m_simplifyWorklist.isEmpty());
-ASSERT(!m_spillWorklist.bitCount());
+ASSERT(m_spillWorklist.isEmpty());
// Reclaim as much memory as possible.
m_interferenceEdges.clear();
@@ -669,7 +669,7 @@
assertInvariants();
}
-if (m_spillWorklist.bitCount()) {
+if (!m_spillWorklist.isEmpty()) {
selectSpill();
changed = true;
ASSERT(m_simplifyWorklist.size() == 1);
@@ -678,7 +678,7 @@
if (!ASSERT_DISABLED) {
ASSERT(!m_simplifyWorklist.size());
-ASSERT(!m_spillWorklist.bitCount());
+ASSERT(m_spillWorklist.isEmpty());
IndexType firstNonRegIndex = m_lastPrecoloredRegisterIndex + 1;
for (IndexType i = firstNonRegIndex; i < m_degrees.size(); ++i)
ASSERT(hasBeenSimplified(i));
@@ -992,7 +992,7 @@
coalesce();
else if (!m_freezeWorklist.isEmpty())
freeze();
-else if (m_spillWorklist.bitCount())
+else if (!m_spillWorklist.isEmpty())
selectSpill();
if (traceDebug) {
@@ -999,7 +999,7 @@
dataLog("After Graph simplification iteration\n");
dumpWorkLists(WTF::dataFile());
}
-} while (!m_simplifyWorklist.isEmpty() || !m_worklistMoves.isEmpty() || !m_freezeWorklist.isEmpty() || m_spillWorklist.bitCount());
+} while (!m_simplifyWorklist.isEmpty() || !m_worklistMoves.isEmpty() || !m_freezeWorklist.isEmpty() || !m_spillWorklist.isEmpty());
assignColors();
}
Modified: trunk/Source/WTF/ChangeLog (245029 => 245030)
--- trunk/Source/WTF/ChangeLog 2019-05-07 20:32:04 UTC (rev 245029)
+++ trunk/Source/WTF/ChangeLog 2019-05-07 20:46:43 UTC (rev 245030)
@@ -1,3 +1,15 @@
+2019-05-07 Robin Morisset
+
+WTF::BitVector should have an isEmpty() method
+https://bugs.webkit.org/show_bug.cgi?id=197637
+
+Reviewed by Keith Miller.
+
+* wtf/BitVector.cpp:
+(WTF::BitVector::isEmptySlow const):
+* wtf/BitVector.h:
+(WTF::BitVector::isEmpty const):
+
2019-05-07 Brent Fulgham
Correct JSON parser to address unterminated escape character
Modified: trunk/Source/WTF/wtf/BitVector.cpp (245029 => 245030)
--- trunk/Source/WTF/wtf/BitVector.cpp 2019-05-07 20:32:04 UTC (rev 245029)
+++ trunk/Source/WTF/wtf/BitVector.cpp 2019-05-07 20:46:43 UTC (rev 245030)
@@ -181,6 +181,17 @@
return result;
}
+bool BitVector::isEmptySlow() const
+{
+ASSERT(!isInline());
+const OutOfLineBits* bits = outOfLineBits();
+for (unsigned i = bits->numWords(); i--;) {
+if (bits->bits()[i])
+return false;
+}
+return true;
+}
+
bool BitVector::equalsSlowCase(const BitVector& other) const
{
bool result = equalsSlowCaseFast(other);
Modified: trunk/Source/WTF/wtf/BitVector.h (245029 => 245030)
--- trunk/Source/WTF/wtf/BitVector.h 2019-05-07 20:32:04 UTC (rev 245029)
+++ trunk/Source/WTF/wtf/BitVector.h 2019-05-07 20:46:43 UTC (rev 245030)
@@ -235,6
[webkit-changes] [244708] trunk
Title: [244708] trunk Revision 244708 Author rmoris...@apple.com Date 2019-04-26 15:21:25 -0700 (Fri, 26 Apr 2019) Log Message All prototypes should call didBecomePrototype() https://bugs.webkit.org/show_bug.cgi?id=196315 Reviewed by Saam Barati. JSTests: * stress/function-prototype-indexed-accessor.js: Added. Source/_javascript_Core: Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor. I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't create structures with invalid prototypes. It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation(). Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype. * runtime/BigIntPrototype.cpp: (JSC::BigIntPrototype::finishCreation): * runtime/BooleanPrototype.cpp: (JSC::BooleanPrototype::finishCreation): * runtime/DatePrototype.cpp: (JSC::DatePrototype::finishCreation): * runtime/ErrorConstructor.cpp: (JSC::ErrorConstructor::finishCreation): * runtime/ErrorPrototype.cpp: (JSC::ErrorPrototype::finishCreation): * runtime/FunctionConstructor.cpp: (JSC::FunctionConstructor::finishCreation): * runtime/FunctionPrototype.cpp: (JSC::FunctionPrototype::finishCreation): * runtime/IntlCollatorPrototype.cpp: (JSC::IntlCollatorPrototype::finishCreation): * runtime/IntlDateTimeFormatPrototype.cpp: (JSC::IntlDateTimeFormatPrototype::finishCreation): * runtime/IntlNumberFormatPrototype.cpp: (JSC::IntlNumberFormatPrototype::finishCreation): * runtime/IntlPluralRulesPrototype.cpp: (JSC::IntlPluralRulesPrototype::finishCreation): * runtime/JSArrayBufferPrototype.cpp: (JSC::JSArrayBufferPrototype::finishCreation): * runtime/JSDataViewPrototype.cpp: (JSC::JSDataViewPrototype::finishCreation): * runtime/JSGenericTypedArrayViewPrototypeInlines.h: (JSC::JSGenericTypedArrayViewPrototype::finishCreation): * runtime/JSGlobalObject.cpp: (JSC::createConsoleProperty): * runtime/JSPromisePrototype.cpp: (JSC::JSPromisePrototype::finishCreation): * runtime/JSTypedArrayViewConstructor.cpp: (JSC::JSTypedArrayViewConstructor::finishCreation): * runtime/JSTypedArrayViewPrototype.cpp: (JSC::JSTypedArrayViewPrototype::finishCreation): * runtime/NumberPrototype.cpp: (JSC::NumberPrototype::finishCreation): * runtime/RegExpPrototype.cpp: (JSC::RegExpPrototype::finishCreation): * runtime/StringPrototype.cpp: (JSC::StringPrototype::finishCreation): * runtime/Structure.cpp: (JSC::Structure::isValidPrototype): (JSC::Structure::changePrototypeTransition): * runtime/Structure.h: * runtime/SymbolPrototype.cpp: (JSC::SymbolPrototype::finishCreation): * wasm/js/WebAssemblyCompileErrorPrototype.cpp: (JSC::WebAssemblyCompileErrorPrototype::finishCreation): * wasm/js/WebAssemblyInstancePrototype.cpp: (JSC::WebAssemblyInstancePrototype::finishCreation): * wasm/js/WebAssemblyLinkErrorPrototype.cpp: (JSC::WebAssemblyLinkErrorPrototype::finishCreation): * wasm/js/WebAssemblyMemoryPrototype.cpp: (JSC::WebAssemblyMemoryPrototype::finishCreation): * wasm/js/WebAssemblyModulePrototype.cpp: (JSC::WebAssemblyModulePrototype::finishCreation): * wasm/js/WebAssemblyPrototype.cpp: (JSC::WebAssemblyPrototype::finishCreation): * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp: (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation): * wasm/js/WebAssemblyTablePrototype.cpp: (JSC::WebAssemblyTablePrototype::finishCreation): Source/WebCore: It was found by existing tests, with the new assert in JSC::Structure * bindings/js/JSWindowProxy.cpp: (WebCore::JSWindowProxy::setWindow): * bindings/scripts/CodeGeneratorJS.pm: (GeneratePrototypeDeclaration): (GenerateConstructorHelperMethods): Modified Paths trunk/JSTests/ChangeLog trunk/Source/_javascript_Core/ChangeLog trunk/Source/_javascript_Core/runtime/BigIntPrototype.cpp trunk/Source/_javascript_Core/runtime/BooleanPrototype.cpp trunk/Source/_javascript_Core/runtime/DatePrototype.cpp trunk/Source/_javascript_Core/runtime/ErrorConstructor.cpp trunk/Source/_javascript_Core/runtime/ErrorPrototype.cpp trunk/Source/_javascript_Core/runtime/FunctionConstructor.cpp trunk/Source/_javascript_Core/runtime/FunctionPrototype.cpp trunk/Source/_javascript_Core/runtime/IntlCollatorPrototype.cpp trunk/Source/_javascript_Core/runtime/IntlDateTimeFormatPrototype.cpp trunk/Source/_javascript_Core/runtime/IntlNumberFormatPrototype.cpp trunk/Source/_javascript_Core/runtime/IntlPluralRulesPrototype.cpp trunk/Source/_javascript_Core/runtime/JSArrayBufferPrototype.cpp trunk/Source/_javascript_Core/runtime/JSDataViewPrototype.cpp trunk/Source/_javascript_Core/runtime/JSGenericTypedArrayViewPrototypeInlines.h trunk/Source/_javascript_Core/runtime/JSGlobalObject.cpp trunk/Source/_javascript_Core/runtime/JSPromisePrototype.cpp trunk/Source/_javascript_Core/runtime/JSTypedArrayViewConstructor.cpp trunk/Source/_javascript_Core/runtime/JSTypedArrayViewPrototype.cpp
