RESOLVED FIXED Bug 142647
Bytecode liveness analysis should have more lambdas and fewer sets
https://bugs.webkit.org/show_bug.cgi?id=142647
Summary Bytecode liveness analysis should have more lambdas and fewer sets
Filip Pizlo
Reported 2015-03-12 16:04:15 PDT
Patch forthcoming.
Attachments
the patch (11.45 KB, patch)
2015-03-12 16:27 PDT, Filip Pizlo
mark.lam: review+
Filip Pizlo
Comment 1 2015-03-12 16:27:55 PDT
Created attachment 248552 [details] the patch
WebKit Commit Bot
Comment 2 2015-03-12 16:30:16 PDT
Attachment 248552 [details] did not pass style-queue: ERROR: Source/JavaScriptCore/bytecode/BytecodeLivenessAnalysis.cpp:121: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/bytecode/BytecodeLivenessAnalysis.cpp:127: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/bytecode/BytecodeLivenessAnalysis.cpp:145: Place brace on its own line for function definitions. [whitespace/braces] [4] ERROR: Source/JavaScriptCore/bytecode/BytecodeLivenessAnalysis.cpp:149: Place brace on its own line for function definitions. [whitespace/braces] [4] Total errors found: 4 in 6 files If any of these errors are false positives, please file a bug against check-webkit-style.
Mark Lam
Comment 3 2015-03-12 16:54:04 PDT
Comment on attachment 248552 [details] the patch View in context: https://bugs.webkit.org/attachment.cgi?id=248552&action=review r=me > Source/JavaScriptCore/bytecode/BytecodeLivenessAnalysis.cpp:130 > + computeDefsForBytecodeOffset( > + codeBlock, bytecodeOffset, > + [&] (CodeBlock* codeBlock, Instruction*, OpcodeID, int operand) { > + if (isValidRegisterForLiveness(codeBlock, operand)) > + def(indexForOperand(codeBlock, operand)); > + }); > + computeUsesForBytecodeOffset( > + codeBlock, bytecodeOffset, > + [&] (CodeBlock* codeBlock, Instruction*, OpcodeID, int operand) { > + if (isValidRegisterForLiveness(codeBlock, operand)) > + use(indexForOperand(codeBlock, operand)); > + }); nit: Everywhere else, we deal with the use case before the def case (including the original code, the template parameters. and the order the functions are defined in the caller). Swapping these 2 calls will make it easier to read.
Filip Pizlo
Comment 4 2015-03-12 16:57:52 PDT
(In reply to comment #3) > Comment on attachment 248552 [details] > the patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=248552&action=review > > r=me > > > Source/JavaScriptCore/bytecode/BytecodeLivenessAnalysis.cpp:130 > > + computeDefsForBytecodeOffset( > > + codeBlock, bytecodeOffset, > > + [&] (CodeBlock* codeBlock, Instruction*, OpcodeID, int operand) { > > + if (isValidRegisterForLiveness(codeBlock, operand)) > > + def(indexForOperand(codeBlock, operand)); > > + }); > > + computeUsesForBytecodeOffset( > > + codeBlock, bytecodeOffset, > > + [&] (CodeBlock* codeBlock, Instruction*, OpcodeID, int operand) { > > + if (isValidRegisterForLiveness(codeBlock, operand)) > > + use(indexForOperand(codeBlock, operand)); > > + }); > > nit: Everywhere else, we deal with the use case before the def case > (including the original code, the template parameters. and the order the > functions are defined in the caller). Swapping these 2 calls will make it > easier to read. It's true that we do that everywhere else; whenever the ordering doesn't matter we say "use" before we say "def". But here the ordering does matter. We must process defs before we process uses.
Filip Pizlo
Comment 5 2015-03-12 19:03:05 PDT
Note You need to log in before you can comment on or make changes to this bug.