AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
22b715f01e
skia2/resources/SkVMTest.expected

329 lines
6.5 KiB
Plaintext
Raw Normal View History

streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
A8 over A8
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
7 registers, 15 instructions:
r0 = splat 3B808081 (0.0039215689)
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
r1 = splat 3F800000 (1)
r2 = splat 437F0000 (255)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r3 = splat 3F000000 (0.5)
loop:
r4 = load8 arg(0)
r4 = to_f32 r4
r4 = mul_f32 r0 r4
r5 = load8 arg(1)
r5 = to_f32 r5
r5 = mul_f32 r0 r5
r6 = sub_f32 r1 r4
r6 = mad_f32 r5 r6 r4
r6 = mad_f32 r6 r2 r3
r6 = to_i32 r6
store8 arg(1) r6
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
A8 over G8
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
9 registers, 21 instructions:
r0 = splat 3B808081 (0.0039215689)
add a x*y+0 -> x*y peephole This is mostly to test how easy rebaselining SkVMTest is. Change-Id: I27ab6f6bb8b7e126327374009783afd86d416f55 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218039 Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-03 21:32:49 +00:00
r1 = splat 3F800000 (1)
r2 = splat 3E59B3D0 (0.21259999)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r3 = splat 3F371759 (0.71520001)
r4 = splat 3D93DD98 (0.0722)
r5 = splat 437F0000 (255)
r6 = splat 3F000000 (0.5)
loop:
r7 = load8 arg(0)
r7 = to_f32 r7
r7 = mul_f32 r0 r7
r8 = load8 arg(1)
r8 = to_f32 r8
r8 = mul_f32 r0 r8
r7 = sub_f32 r1 r7
r7 = mul_f32 r8 r7
r8 = mul_f32 r7 r4
r8 = mad_f32 r7 r3 r8
r8 = mad_f32 r7 r2 r8
r8 = mad_f32 r8 r5 r6
r8 = to_i32 r8
store8 arg(1) r8
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
A8 over RGBA_8888
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
11 registers, 38 instructions:
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r0 = splat 3B808081 (0.0039215689)
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r1 = splat FF (3.5733111e-43)
r2 = splat 3F800000 (1)
r3 = splat 437F0000 (255)
r4 = splat 3F000000 (0.5)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
loop:
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r5 = load8 arg(0)
r5 = to_f32 r5
r5 = mul_f32 r0 r5
r6 = load32 arg(1)
r7 = extract r6 0 r1
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r7 = to_f32 r7
r7 = mul_f32 r0 r7
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r8 = extract r6 8 r1
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r8 = to_f32 r8
r8 = mul_f32 r0 r8
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r9 = extract r6 16 r1
r9 = to_f32 r9
r9 = mul_f32 r0 r9
r6 = extract r6 24 r1
r6 = to_f32 r6
r6 = mul_f32 r0 r6
r10 = sub_f32 r2 r5
r7 = mul_f32 r7 r10
r8 = mul_f32 r8 r10
r9 = mul_f32 r9 r10
r10 = mad_f32 r6 r10 r5
r7 = mad_f32 r7 r3 r4
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r7 = to_i32 r7
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r8 = mad_f32 r8 r3 r4
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r8 = to_i32 r8
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r9 = mad_f32 r9 r3 r4
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r9 = to_i32 r9
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r10 = mad_f32 r10 r3 r4
r10 = to_i32 r10
r8 = pack r7 r8 8
r10 = pack r9 r10 8
r10 = pack r8 r10 16
store32 arg(1) r10
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
G8 over A8
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
6 registers, 12 instructions:
Revert "print 1/K floats as fractions" This reverts commit 346f82c1c3e0b302e46b0850b4ac63b21d263697. Reason for revert: *SAN bots Original change's description: > print 1/K floats as fractions > > Change-Id: Id00cbd0950e77debb5ab5d45541dc0f8d13a3c42 > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218338 > Reviewed-by: Brian Osman <brianosman@google.com> > Commit-Queue: Mike Klein <mtklein@google.com> TBR=mtklein@google.com,brianosman@google.com Change-Id: Ic35cec97d2dc2c1e19dbdf8ea7b505ad75072da1 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218529 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 14:12:16 +00:00
r0 = splat 3B808081 (0.0039215689)
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
r1 = splat 3F800000 (1)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r2 = sub_f32 r1 r1
r3 = splat 437F0000 (255)
r4 = splat 3F000000 (0.5)
loop:
r5 = load8 arg(1)
r5 = to_f32 r5
r5 = mul_f32 r0 r5
r5 = mad_f32 r5 r2 r1
r5 = mad_f32 r5 r3 r4
r5 = to_i32 r5
store8 arg(1) r5
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
G8 over G8
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
10 registers, 21 instructions:
r0 = splat 3B808081 (0.0039215689)
r1 = splat 3F800000 (1)
r2 = sub_f32 r1 r1
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
r3 = splat 3E59B3D0 (0.21259999)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r4 = splat 3F371759 (0.71520001)
r5 = splat 3D93DD98 (0.0722)
r6 = splat 437F0000 (255)
r7 = splat 3F000000 (0.5)
loop:
r8 = load8 arg(0)
r8 = to_f32 r8
r8 = mul_f32 r0 r8
r9 = load8 arg(1)
r9 = to_f32 r9
r9 = mul_f32 r0 r9
r9 = mad_f32 r9 r2 r8
r8 = mul_f32 r9 r5
r8 = mad_f32 r9 r4 r8
r8 = mad_f32 r9 r3 r8
r8 = mad_f32 r8 r6 r7
r8 = to_i32 r8
store8 arg(1) r8
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
G8 over RGBA_8888
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
11 registers, 38 instructions:
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r0 = splat 3B808081 (0.0039215689)
r1 = splat 3F800000 (1)
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r2 = splat FF (3.5733111e-43)
r3 = sub_f32 r1 r1
r4 = splat 437F0000 (255)
r5 = splat 3F000000 (0.5)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
loop:
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r6 = load8 arg(0)
r6 = to_f32 r6
r6 = mul_f32 r0 r6
r7 = load32 arg(1)
r8 = extract r7 0 r2
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r8 = to_f32 r8
r8 = mul_f32 r0 r8
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r9 = extract r7 8 r2
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r9 = to_f32 r9
r9 = mul_f32 r0 r9
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r10 = extract r7 16 r2
r10 = to_f32 r10
r10 = mul_f32 r0 r10
r7 = extract r7 24 r2
r7 = to_f32 r7
r7 = mul_f32 r0 r7
r8 = mad_f32 r8 r3 r6
r9 = mad_f32 r9 r3 r6
r10 = mad_f32 r10 r3 r6
r7 = mad_f32 r7 r3 r1
r8 = mad_f32 r8 r4 r5
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r8 = to_i32 r8
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r9 = mad_f32 r9 r4 r5
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r9 = to_i32 r9
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r10 = mad_f32 r10 r4 r5
r10 = to_i32 r10
r7 = mad_f32 r7 r4 r5
r7 = to_i32 r7
r9 = pack r8 r9 8
r7 = pack r10 r7 8
r7 = pack r9 r7 16
store32 arg(1) r7
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
RGBA_8888 over A8
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
8 registers, 17 instructions:
r0 = splat FF (3.5733111e-43)
r1 = splat 3B808081 (0.0039215689)
r2 = splat 3F800000 (1)
r3 = splat 437F0000 (255)
r4 = splat 3F000000 (0.5)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
loop:
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r5 = load32 arg(0)
r5 = extract r5 24 r0
add extract instruction Kind of the flip side of pack. Made slightly awkward by instructions having only one immediate... calling _BitScanForward / __builtin_ctz() at runtime seems to work fine, but it really could have been done at compile time. Change-Id: Ic83fe8e0a1603fb9189598dcc26c842cc797bf45 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218241 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-04 16:33:25 +00:00
r5 = to_f32 r5
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r5 = mul_f32 r1 r5
r6 = load8 arg(1)
r6 = to_f32 r6
r6 = mul_f32 r1 r6
r7 = sub_f32 r2 r5
r7 = mad_f32 r6 r7 r5
r7 = mad_f32 r7 r3 r4
r7 = to_i32 r7
store8 arg(1) r7
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
RGBA_8888 over G8
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
13 registers, 34 instructions:
r0 = splat FF (3.5733111e-43)
r1 = splat 3B808081 (0.0039215689)
r2 = splat 3F800000 (1)
r3 = splat 3E59B3D0 (0.21259999)
r4 = splat 3F371759 (0.71520001)
r5 = splat 3D93DD98 (0.0722)
r6 = splat 437F0000 (255)
r7 = splat 3F000000 (0.5)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
loop:
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r8 = load32 arg(0)
r9 = extract r8 0 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r9 = to_f32 r9
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r9 = mul_f32 r1 r9
r10 = extract r8 8 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r10 = to_f32 r10
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r10 = mul_f32 r1 r10
r11 = extract r8 16 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r11 = to_f32 r11
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r11 = mul_f32 r1 r11
r8 = extract r8 24 r0
r8 = to_f32 r8
r8 = mul_f32 r1 r8
r12 = load8 arg(1)
r12 = to_f32 r12
r12 = mul_f32 r1 r12
r8 = sub_f32 r2 r8
r9 = mad_f32 r12 r8 r9
r10 = mad_f32 r12 r8 r10
r8 = mad_f32 r12 r8 r11
r8 = mul_f32 r8 r5
r8 = mad_f32 r10 r4 r8
r8 = mad_f32 r9 r3 r8
r8 = mad_f32 r8 r6 r7
r8 = to_i32 r8
store8 arg(1) r8
streamline SkVM test rebaselining - keep expectations in resources/ - overwrite automatically if needed so we can see the diff in Git Change-Id: I2486b127ebcc7f40332fd0462e38b1af04d3e32b Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218038 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 21:27:46 +00:00
RGBA_8888 over RGBA_8888
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
14 registers, 48 instructions:
r0 = splat FF (3.5733111e-43)
r1 = splat 3B808081 (0.0039215689)
r2 = splat 3F800000 (1)
r3 = splat 437F0000 (255)
r4 = splat 3F000000 (0.5)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
loop:
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r5 = load32 arg(0)
r6 = extract r5 0 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r6 = to_f32 r6
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r6 = mul_f32 r1 r6
r7 = extract r5 8 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r7 = to_f32 r7
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r7 = mul_f32 r1 r7
r8 = extract r5 16 r0
r8 = to_f32 r8
r8 = mul_f32 r1 r8
r5 = extract r5 24 r0
r5 = to_f32 r5
r5 = mul_f32 r1 r5
r9 = load32 arg(1)
r10 = extract r9 0 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r10 = to_f32 r10
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r10 = mul_f32 r1 r10
r11 = extract r9 8 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r11 = to_f32 r11
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r11 = mul_f32 r1 r11
r12 = extract r9 16 r0
r12 = to_f32 r12
r12 = mul_f32 r1 r12
r9 = extract r9 24 r0
r9 = to_f32 r9
r9 = mul_f32 r1 r9
r13 = sub_f32 r2 r5
r10 = mad_f32 r10 r13 r6
r11 = mad_f32 r11 r13 r7
r12 = mad_f32 r12 r13 r8
r13 = mad_f32 r9 r13 r5
r10 = mad_f32 r10 r3 r4
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r10 = to_i32 r10
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r11 = mad_f32 r11 r3 r4
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r11 = to_i32 r11
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r12 = mad_f32 r12 r3 r4
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r12 = to_i32 r12
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r13 = mad_f32 r13 r3 r4
r13 = to_i32 r13
r11 = pack r10 r11 8
r13 = pack r12 r13 8
r13 = pack r11 r13 16
store32 arg(1) r13
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
I32 8888 over 8888
add mad_unorm8 instruction At some point adding more and more complex instructions reduces to the absurdity of SolveTheWholeProblem-The-Instruction, but I think this one will come up often enough to still make sense. mad() makes sense for unorm8 just about everywhere mad() makes sense for f32. This instruction won't matter to a JIT, but helps the interpreter. Change-Id: Iace92296cffbb6fbc3acd1f853cb01c51792f796 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218716 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-05 19:20:41 +00:00
10 registers, 20 instructions:
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r0 = splat FF (3.5733111e-43)
loop:
r1 = load32 arg(0)
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r2 = extract r1 0 r0
r3 = extract r1 8 r0
r4 = extract r1 16 r0
r1 = extract r1 24 r0
add extract instruction Kind of the flip side of pack. Made slightly awkward by instructions having only one immediate... calling _BitScanForward / __builtin_ctz() at runtime seems to work fine, but it really could have been done at compile time. Change-Id: Ic83fe8e0a1603fb9189598dcc26c842cc797bf45 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218241 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-04 16:33:25 +00:00
r5 = load32 arg(1)
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r6 = extract r5 0 r0
r7 = extract r5 8 r0
r8 = extract r5 16 r0
r5 = extract r5 24 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r9 = sub_i32 r0 r1
add mad_unorm8 instruction At some point adding more and more complex instructions reduces to the absurdity of SolveTheWholeProblem-The-Instruction, but I think this one will come up often enough to still make sense. mad() makes sense for unorm8 just about everywhere mad() makes sense for f32. This instruction won't matter to a JIT, but helps the interpreter. Change-Id: Iace92296cffbb6fbc3acd1f853cb01c51792f796 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218716 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-05 19:20:41 +00:00
r6 = mad_unorm8 r6 r9 r2
r7 = mad_unorm8 r7 r9 r3
r8 = mad_unorm8 r8 r9 r4
r9 = mad_unorm8 r5 r9 r1
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r7 = pack r6 r7 8
r9 = pack r8 r9 8
r9 = pack r7 r9 16
store32 arg(1) r9
centralize test/bench SkVM builders Eliminate the duplicate functionality, and better testing for the bench builders. Change-Id: If20e52107738903f854aec431416e573d7a7d640 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218041 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 22:10:59 +00:00
I32 (SWAR) 8888 over 8888
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
7 registers, 20 instructions:
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r0 = splat FF00FF (2.3418409e-38)
r1 = splat FF (3.5733111e-43)
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
loop:
r2 = load32 arg(0)
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r3 = extract r2 0 r0
r2 = extract r2 8 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r4 = load32 arg(1)
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r5 = extract r4 0 r0
r4 = extract r4 8 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r6 = shr r2 16
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r6 = sub_i32 r1 r6
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r5 = mul_i32 r5 r6
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r5 = add_i32 r5 r0
r5 = extract r5 8 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r5 = add_i32 r3 r5
r6 = mul_i32 r4 r6
revise extract instruction Convert extract(x,bits,z) to be (x >> bits) & z, now a more explicit parallel to pack(). This lets us eliminate the funky bit counting required from the old instruction, but more saliently it makes it more likely that the masks we AND with will be the same value. Ultimately down at the x86 or ARM ISA level, the AND instructions don't really benefit from having an immediate argument (while the shifts do). We might as well treat the mask as a normal value, letting it get commoned with identical values, loop hoisted, etc. Change-Id: I48a38468b46f2c730574c025f412262296472447 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219597 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-07 20:44:26 +00:00
r6 = add_i32 r6 r0
r6 = extract r6 8 r0
hoist loop-invariant code out of the loop I'm of two minds about this... it adds register pressure and really only tends to hoist few instructions that are fairly cheap anway. On the other hand, it's neat, it's easy to turn off (just set the initial hoist value to false in Builder::push()) and it does deliver a noticeable though slight performance improvement in the interpreter. I think the final decision will probably come down to what we think about maintainability? Change-Id: Idd6346f70f03188917918406731154246a7c6fcb Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218584 Reviewed-by: Brian Osman <brianosman@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-05 15:47:46 +00:00
r6 = add_i32 r2 r6
r6 = pack r5 r6 8
store32 arg(1) r6
centralize test/bench SkVM builders Eliminate the duplicate functionality, and better testing for the bench builders. Change-Id: If20e52107738903f854aec431416e573d7a7d640 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/218041 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-03 22:10:59 +00:00
Reference in New Issue Copy Permalink