AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fix indenting on InlineCandidateAnalyzer.

Browse Source 
No code changes in this CL, only hundreds of lines of indentation fixes.

Change-Id: I780a0f93a61e567c4dca0e8b8d7066350569dc55
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/321795
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This commit is contained in:
John Stiles 2020-10-02 16:42:10 -04:00 committed by Skia Commit-Bot
parent a6ca9757d3
commit 70957c8bc8
1 changed files with 271 additions and 273 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
src/sksl/SkSLInliner.cpp
View File

@ -791,12 +791,12 @@ class InlineCandidateAnalyzer {
// A list of all the inlining candidates we found during analysis.
InlineCandidateList* fCandidateList;
// A stack of the symbol tables; since most nodes don't have one, expected to be shallower
// than the enclosing-statement stack.
// A stack of the symbol tables; since most nodes don't have one, expected to be shallower than
// the enclosing-statement stack.
std::vector<SymbolTable*> fSymbolTableStack;
// A stack of "enclosing" statements--these would be suitable for the inliner to use for
// adding new instructions. Not all statements are suitable (e.g. a for-loop's initializer).
// The inliner might replace a statement with a block containing the statement.
// A stack of "enclosing" statements--these would be suitable for the inliner to use for adding
// new instructions. Not all statements are suitable (e.g. a for-loop's initializer). The
// inliner might replace a statement with a block containing the statement.
std::vector<std::unique_ptr<Statement>*> fEnclosingStmtStack;
// The function that we're currently processing (i.e. inlining into).
FunctionDefinition* fEnclosingFunction = nullptr;
@ -867,11 +867,11 @@ class InlineCandidateAnalyzer {
// loop at this time. There are two limitations:
// - We would need to insert the inlined-body block at the very end of the do-
// statement's inner fStatement. We don't support that today, but it's doable.
// - We cannot inline the test expression if the loop uses `continue` anywhere;
// that would skip over the inlined block that evaluates the test expression.
// There isn't a good fix for this--any workaround would be more complex than
// the cost of a function call. However, loops that don't use `continue` would
// still be viable candidates for inlining.
// - We cannot inline the test expression if the loop uses `continue` anywhere; that
// would skip over the inlined block that evaluates the test expression. There
// isn't a good fix for this--any workaround would be more complex than the cost
// of a function call. However, loops that don't use `continue` would still be
// viable candidates for inlining.
break;
}
case Statement::Kind::kExpression: {
@ -892,19 +892,18 @@ class InlineCandidateAnalyzer {
// The inliner isn't smart enough to inline the test- or increment-expressions
// of a for loop loop at this time. There are a handful of limitations:
// - We would need to insert the test-expression block at the very beginning of
// the for-loop's inner fStatement, and the increment-expression block at the
// very end. We don't support that today, but it's doable.
// - We would need to insert the test-expression block at the very beginning of the
// for-loop's inner fStatement, and the increment-expression block at the very
// end. We don't support that today, but it's doable.
// - The for-loop's built-in test-expression would need to be dropped entirely,
// and the loop would be halted via a break statement at the end of the
// inlined test-expression. This is again something we don't support today,
// but it could be implemented.
// - We cannot inline the increment-expression if the loop uses `continue`
// anywhere; that would skip over the inlined block that evaluates the
// increment expression. There isn't a good fix for this--any workaround would
// be more complex than the cost of a function call. However, loops that don't
// use `continue` would still be viable candidates for increment-expression
// inlining.
// and the loop would be halted via a break statement at the end of the inlined
// test-expression. This is again something we don't support today, but it could
// be implemented.
// - We cannot inline the increment-expression if the loop uses `continue` anywhere;
// that would skip over the inlined block that evaluates the increment expression.
// There isn't a good fix for this--any workaround would be more complex than the
// cost of a function call. However, loops that don't use `continue` would still
// be viable candidates for increment-expression inlining.
break;
}
case Statement::Kind::kIf: {
@ -951,15 +950,14 @@ class InlineCandidateAnalyzer {
WhileStatement& whileStmt = (*stmt)->as<WhileStatement>();
// The loop body is a candidate for inlining.
this->visitStatement(&whileStmt.fStatement);
// The inliner isn't smart enough to inline the test-expression for a while
// loop at this time. There are two limitations:
// The inliner isn't smart enough to inline the test-expression for a while loop at
// this time. There are two limitations:
// - We would need to insert the inlined-body block at the very beginning of the
// while loop's inner fStatement. We don't support that today, but it's
// doable.
// while loop's inner fStatement. We don't support that today, but it's doable.
// - The while-loop's built-in test-expression would need to be replaced with a
// `true` BoolLiteral, and the loop would be halted via a break statement at
// the end of the inlined test-expression. This is again something we don't
// support today, but it could be implemented.
// `true` BoolLiteral, and the loop would be halted via a break statement at the
// end of the inlined test-expression. This is again something we don't support
// today, but it could be implemented.
break;
}
default:
@ -1001,8 +999,8 @@ class InlineCandidateAnalyzer {
// (false && x()) // always false
// (true || y()) // always true
// It is illegal for side-effects from x() or y() to occur. The simplest way to
// enforce that rule is to avoid inlining the right side entirely. However, it
// is safe for other types of binary expression to inline both sides.
// enforce that rule is to avoid inlining the right side entirely. However, it is
// safe for other types of binary expression to inline both sides.
Token::Kind op = binaryExpr.getOperator();
bool shortCircuitable = (op == Token::Kind::TK_LOGICALAND ||
op == Token::Kind::TK_LOGICALOR);
@ -1058,8 +1056,8 @@ class InlineCandidateAnalyzer {
TernaryExpression& ternaryExpr = (*expr)->as<TernaryExpression>();
// The test expression is a candidate for inlining.
this->visitExpression(&ternaryExpr.fTest);
// The true- and false-expressions cannot be inlined, because we are only
// allowed to evaluate one side.
// The true- and false-expressions cannot be inlined, because we are only allowed to
// evaluate one side.
break;
}
default: