Bug 142647

Summary: Bytecode liveness analysis should have more lambdas and fewer sets
Product: WebKit Reporter: Filip Pizlo <fpizlo>
Component: JavaScriptCoreAssignee: Filip Pizlo <fpizlo>
Status: RESOLVED FIXED    
Severity: Normal CC: barraclough, benjamin, cmarcelo, commit-queue, ggaren, mark.lam, mhahnenb, mmirman, msaboff, nrotem, oliver, saam, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 141174    
Attachments:
Description Flags
the patch mark.lam: review+

Description Filip Pizlo 2015-03-12 16:04:15 PDT
Patch forthcoming.
Comment 1 Filip Pizlo 2015-03-12 16:27:55 PDT
Created attachment 248552 [details]
the patch
Comment 2 WebKit Commit Bot 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.
Comment 3 Mark Lam 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.
Comment 4 Filip Pizlo 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.
Comment 5 Filip Pizlo 2015-03-12 19:03:05 PDT
Landed in http://trac.webkit.org/changeset/181467