This reverts commit e81fb87bb4.
Reason for revert: checking results with less-aggressive inliner
Original change's description:
> Revert "Simplify _blend_set_color_saturation, removing an instruction."
>
> This reverts commit ed289e777c.
>
> Reason for revert: causing strange artifacts, only on Adreno
>
> Original change's description:
> > Simplify _blend_set_color_saturation, removing an instruction.
> >
> > This tightens up our intrinsics slightly; after inlining, it eliminates
> > one scratch variable. (We no longer need to copy `sda` into `hueColor`
> > as hueColor is now unchanged.)
> >
> > Change-Id: Iece5ba2fe11cde54481704a1787114a2c2a66d9b
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/336599
> > 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>
>
> TBR=brianosman@google.com,johnstiles@google.com
>
> Change-Id: Ica506467b0a4e03d0cbe482034acfa2d9f8d2c16
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337560
> Reviewed-by: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,johnstiles@google.com
Change-Id: Ia93263f3269c057e7eaa69ca2b05e783d18c0199
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337944
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Previously, we'd gauge suitability for inlining by counting the nodes in
a function; past a certain limit, the function was considered "too big."
Now, we also incorporate the number of times that function is called.
So if a function is called three times, and its size is 20 nodes, it
would be considered to have an inlining cost of 60 (3 * 20) instead of
20.
This should tamp down the aggressive nature of the inliner in cases like
gaussian convolution or complicated blends, and will hopefully satisfy
Pinpoint.
No change visible in Nanobench (which doesn't test any of these sorts of
patterns, but certainly inlines things): http://screen/AwD5hkgkEfjVx4g
Change-Id: Ie5e32898245ac854adb9ddd52d87001df6a67125
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337676
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This reverts commit ed289e777c.
Reason for revert: causing strange artifacts, only on Adreno
Original change's description:
> Simplify _blend_set_color_saturation, removing an instruction.
>
> This tightens up our intrinsics slightly; after inlining, it eliminates
> one scratch variable. (We no longer need to copy `sda` into `hueColor`
> as hueColor is now unchanged.)
>
> Change-Id: Iece5ba2fe11cde54481704a1787114a2c2a66d9b
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/336599
> 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>
TBR=brianosman@google.com,johnstiles@google.com
Change-Id: Ica506467b0a4e03d0cbe482034acfa2d9f8d2c16
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337560
Reviewed-by: John Stiles <johnstiles@google.com>
We now have SPIR-V golden outputs for `blend` and `shared` tests.
This exposes a handful of SPIR-V limitations for us to address.
Change-Id: Ie5278889b8a61432403d06231b17765885bee0ac
Bug: skia:10694
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/337182
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>
Previously, any builtin functions would be optimized as a side-effect of
optimizing programs that used them. Now that shared elements aren't
being optimized in that way, we explicitly optimize any shared modules
when they are first created. We don't remove dead elements, but we
we do substitute settings, simplify, and inline.
Bug: skia:10905
Change-Id: I701b5e9f52fb880ef3e6f4c67694d08602f47e95
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/336440
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This tightens up our intrinsics slightly; after inlining, it eliminates
one scratch variable. (We no longer need to copy `sda` into `hueColor`
as hueColor is now unchanged.)
Change-Id: Iece5ba2fe11cde54481704a1787114a2c2a66d9b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/336599
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>
This causes a ~4% regression on sksl_large, but some of that
can be bought back in two ways:
1) Removing (now unnecessary) cloning of program elements
2) Hoisting the new analysis passes, with (nontrivial)
logic to update/maintain the call counts as we edit IR.
Also, this fixes bugs where we were emitting functions that
had "calls" from no-longer called functions.
Bug: skia:10776
Change-Id: I4f8c29957be2e4233a883c9a1125f363b82ee40c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/327198
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
This reverts commit 941fc7174f.
Reason for revert: performance now seems to be roughly equal or better
(~1%) over several trials.
Nanobench: http://screen/A8e8sojaXBgbMgF
Original change's description:
> Revert "Remove inliner from IR generation stage."
>
> This reverts commit 21d7778cb5.
>
> Reason for revert: Pinpoint absolutely hates this change
>
> Original change's description:
> > Remove inliner from IR generation stage.
> >
> > There is no need to inline code during IR generation, as the optimizer
> > can now handle this.
> >
> > Change-Id: If272bfb98e945a75ec91fb4aa026e5631ac51b5b
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/315971
> > Commit-Queue: John Stiles <johnstiles@google.com>
> > Commit-Queue: Brian Osman <brianosman@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
> > Auto-Submit: John Stiles <johnstiles@google.com>
>
> TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
>
> Change-Id: I62c235415bcdc92a088e2a7f9c3d7dbf7e1bf669
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317976
> Reviewed-by: John Stiles <johnstiles@google.com>
> Commit-Queue: John Stiles <johnstiles@google.com>
TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com
Change-Id: I6189806c678283188f4b67ee61e5886f88c2d6fc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/324891
Reviewed-by: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
This CL is conceptually a revert of http://review.skia.org/320258,
although the code has changed shape a bit since that CL was landed.
This fix was too aggressive, and can lead to functions being dead-
stripped while they still have an active reference.
Change-Id: I6ce8b0ad9cc2a42e8be8cb10d3a8219149eca6aa
Bug: skia:10776
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/325462
Commit-Queue: John Stiles <johnstiles@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
This removes VarDeclarationsStatement entirely. VarDeclaration instances
appear directly as statements in Programs. SkSL that declares multiple
variables in a single declaration is transformed to represent that as a
series of VarDeclaration statements.
Similarly, global variable declarations are represented by
GlobalVarDeclaration program elements, one per variable.
Bug: skia:10806
Change-Id: Idd8a2d971a8217733ed57f0dd2249d62f2f0e9c5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/323102
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: John Stiles <johnstiles@google.com>
Just a typo fix.
Change-Id: I2fe1f6ae1c99d7f20a4fa5f49eefea514e224652
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/321977
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>
The following types of expression are hoisted directly into the
inlined code:
- Struct field access: `myStruct.myField`
- Swizzles: `myVector.xzy`
- Simple array indexes: `myArray[0]`
This significantly reduces the number of temporary variables generated
by the inliner.
Change-Id: Ifed226ecc87b096ec1e38752c0c38ae32bd31578
Bug: skia:10737, skia:10786
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/319919
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
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>
Previously, we copied intrinsic functions in a totally arbitrary order;
it used an unordered_set of pointers, so it could be affected by
switching standard libraries OR by malloc nondeterminism. (Surprisingly,
it was fairly consistent in practice on OS X/Linux.) This CL sorts the
intrinsic functions into a consistent order before copying them.
Change-Id: If90342bb77a9ae237a3ce91be3a9847311a722c4
Bug: skia:10749
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/318700
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Ethan Nicholas <ethannicholas@google.com>
Ideally the inliner would be smart enough to avoid creating a temporary
at all just for a swizzle, but a good first step is to create fewer of
them.
Change-Id: Icd6f86c294237488f7923dc787bb64a5f99bd0ac
Bug: skia:10737
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/318213
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@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>
I realized that "DefaultSettings" as a name suffix was unclear, because
"Default" is a different settings mode from skslc running with
--nosettings.
In --nosettings mode, skslc uses "standalone" settings.
Change-Id: I1f5d80df0a21cec55948c4ad146169bcb34f4999
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/318210
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: John Stiles <johnstiles@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>
