skia2/tests/sksl/inliner/InlinerAvoidsVariableNameOverlap.glsl


out vec4 sk_FragColor;
vec4 main() {
    vec2 _1_reusedName = vec2(1.0, 2.0);
    vec2 _2_reusedName = _1_reusedName - 1.0;
    return _2_reusedName.xyxy;
}
Demonstrate name reuse error in inliner. The following conditions lead to the error: - A pair of nested functions, both of which must be inlined. - Both inlined functions create a variable with the same name. - The outer function passes its variable to the inner function. - The initialization of the inner variable uses the value from the outer variable. - The inner function does not mutate the variable, use it as an out- parameter, or otherwise cause it to receive a temporary copy. When all these conditions are met, both variable declarations are inlined as-is without performing any name salting, because it's seemingly safe to do so. The name overlap issue is not considered in the safety checks. Inlined variable declarations are not subject to name salting but they should be; I suspect other adversarial examples could be crafted as well where unhandled name overlap leads to errors. Change-Id: Ia754bee8e45c8a5c7548436594bbf04abc7a8396 Bug: skia:10722 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316945 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com> 2020-09-14 22:23:54 +00:00
Support half4 return values from main() in the SPIR-V code generator. This creates a helper function, _entrypoint, which invokes main() and assigns its result into sk_FragColor. We also make sure to prevent sk_FragColor from being dead-stripped from the code during IR generation. At present this is useful for allowing our SkSL test shaders to compile. Change-Id: I2d7fab0e1959a77778ffdb18ca569e869bcaeece Reviewed-on: https://skia-review.googlesource.com/c/skia/+/358525 Commit-Queue: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com> 2021-01-27 00:58:22 +00:00			`out vec4 sk_FragColor;`
Align default values of GrShaderCaps with StandaloneShaderCaps. `fBuiltinFMASupport` is now true on both, and `fUsesPrecisionModifiers` is now false. Other mismatching flags exist, but they are non-trivial to synchronize as they are tied to extension strings. This will help our skslc-based unit tests generate the same results as our C++ unit tests did, but should not affect real-world results as these defaults will all be overwritten in a non-testing scenario. In practice, the `fUsesPrecisionModifiers` change is responsible for all of the diffs below. The other flags did not change the results of any of the currently-ported tests. Change-Id: Ieb056d852b027fa87c56fd89f971a77a10a8a124 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/317204 Commit-Queue: John Stiles <johnstiles@google.com> Reviewed-by: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com> 2020-09-15 20:09:11 +00:00			`vec4 main() {`
Run SkSL inliner tests as part of dm. Previously, these tests were never actually executed, only read during code review. They are now properly tested for correctness whenever dm is run. Non-ES2 compliant statements (do/while/switch) are unfortunately excluded here, as they are not compatible with Runtime Effects yet. Change-Id: I965c782baad6f8dd3961a400ae791fb2c1f844d3 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/389296 Auto-Submit: John Stiles <johnstiles@google.com> Commit-Queue: Ethan Nicholas <ethannicholas@google.com> Reviewed-by: Ethan Nicholas <ethannicholas@google.com> 2021-03-25 21:04:36 +00:00			`vec2 _1_reusedName = vec2(1.0, 2.0);`
			`vec2 _2_reusedName = _1_reusedName - 1.0;`
Revert "Inline functions of the form 'return (expr)' only." This reverts commit 92748af1a5051e9fe329c8200f0fa3b47aadbdd7. Reason for revert: SkSLCommaSideEffects_GPU crashing on Android Original change's description: > Inline functions of the form 'return (expr)' only. > > This drastically reduces the number of functions which we allow to be > inlined. If this change does not hurt our performance, it will allow us > to trivially remove hundreds of LOC. All current data leads us to > believe that it may affect the Mali 400 but is highly unlikely to change > results on any other device in the tree. > > More info: http://go/optimization-in-sksl-inliner > > Change-Id: Ia6b706742ce5407453e0e697b6c1f9201084c0e8 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/384858 > Auto-Submit: John Stiles <johnstiles@google.com> > Commit-Queue: John Stiles <johnstiles@google.com> > Reviewed-by: Brian Osman <brianosman@google.com> > Reviewed-by: Ethan Nicholas <ethannicholas@google.com> TBR=brianosman@google.com,ethannicholas@google.com,johnstiles@google.com Change-Id: I6a670dacaa58fe3386ff50375ac6d1cac4fd7f2c No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/385161 Reviewed-by: John Stiles <johnstiles@google.com> Commit-Queue: John Stiles <johnstiles@google.com> 2021-03-15 22:08:38 +00:00			`return _2_reusedName.xyxy;`
Demonstrate name reuse error in inliner. The following conditions lead to the error: - A pair of nested functions, both of which must be inlined. - Both inlined functions create a variable with the same name. - The outer function passes its variable to the inner function. - The initialization of the inner variable uses the value from the outer variable. - The inner function does not mutate the variable, use it as an out- parameter, or otherwise cause it to receive a temporary copy. When all these conditions are met, both variable declarations are inlined as-is without performing any name salting, because it's seemingly safe to do so. The name overlap issue is not considered in the safety checks. Inlined variable declarations are not subject to name salting but they should be; I suspect other adversarial examples could be crafted as well where unhandled name overlap leads to errors. Change-Id: Ia754bee8e45c8a5c7548436594bbf04abc7a8396 Bug: skia:10722 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/316945 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: John Stiles <johnstiles@google.com> 2020-09-14 22:23:54 +00:00			`}`