This allows dead-stripping to properly optimize away unreferenced clones
of intrinsic functions, and allows the inliner to detect intrinsic
functions that are only called once (which can generally always be
inlined without penalty).
Change-Id: I0cf034d880ae5d52f4cc0f93de6e2c7aad34e975
Bug: skia:10776
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/320258
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Early returns can cause the inliner to generate suboptimal code. We
control our built-ins, so let's avoid them where we can.
Patterns like this challenge the inliner:
if (x) return y;
return z;
But this can be replaced by equivalent code that inlines better:
return x ? y : z;
Or, if a ternary can't be used, this also does a better job:
if (x) return y;
else return z;
In several cases, this allows the inliner to avoid generating a
do-while(false) block for control flow.
Change-Id: I921c929122297c40476ff15b4da631fc1581e308
Bug: skia:10737
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/318211
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Several blend functions generate a surprisingly large amount of code,
and appear to have opportunities for further optimization. At any rate,
if we make compiler changes that would affect the output of a blend
function, I think we would want to see the changes reflected in our
golden outputs.
Change-Id: Iff612dcd4bad8824b5e6e97413ffce19e5ea1c0e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/318336
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
