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

732 lines
15 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
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
17 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v0 = splat 0 (0)
v1 = load8 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v2 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v3 = to_f32 v1
v4 = mul_f32 v2 v3
v5 = load8 arg(1)
v6 = to_f32 v5
v7 = mul_f32 v2 v6
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v8 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v9 = sub_f32 v8 v4
☠️ v10 = mul_f32 v0 v9
v11 = mad_f32 v7 v9 v4
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v12 = splat 437F0000 (255)
↑ v13 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v14 = mad_f32 v11 v12 v13
v15 = to_i32 v14
store8 arg(1) v15
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r4 = mad_f32 r5 r6 r4
r4 = mad_f32 r4 r2 r3
r4 = to_i32 r4
store8 arg(1) r4
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
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
23 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v0 = splat 0 (0)
v1 = load8 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v2 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v3 = to_f32 v1
v4 = mul_f32 v2 v3
v5 = load8 arg(1)
v6 = to_f32 v5
v7 = mul_f32 v2 v6
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v8 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v9 = sub_f32 v8 v4
v10 = mul_f32 v7 v9
☠️ v11 = mad_f32 v8 v9 v4
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v12 = splat 3E59B3D0 (0.21259999)
↑ v13 = splat 3F371759 (0.71520001)
↑ v14 = splat 3D93DD98 (0.0722)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v15 = mul_f32 v10 v14
v16 = mad_f32 v10 v13 v15
v17 = mad_f32 v10 v12 v16
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v18 = splat 437F0000 (255)
↑ v19 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v20 = mad_f32 v17 v18 v19
v21 = to_i32 v20
store8 arg(1) v21
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
39 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v0 = splat 0 (0)
v1 = load8 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v2 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v3 = to_f32 v1
v4 = mul_f32 v2 v3
v5 = load32 arg(1)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v6 = splat FF (3.5733111e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v7 = extract v5 0 v6
v8 = to_f32 v7
v9 = mul_f32 v2 v8
v10 = extract v5 8 v6
v11 = to_f32 v10
v12 = mul_f32 v2 v11
v13 = extract v5 16 v6
v14 = to_f32 v13
v15 = mul_f32 v2 v14
v16 = extract v5 24 v6
v17 = to_f32 v16
v18 = mul_f32 v2 v17
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v19 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v20 = sub_f32 v19 v4
v21 = mul_f32 v9 v20
v22 = mul_f32 v12 v20
v23 = mul_f32 v15 v20
v24 = mad_f32 v18 v20 v4
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v25 = splat 437F0000 (255)
↑ v26 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v27 = mad_f32 v21 v25 v26
v28 = to_i32 v27
v29 = mad_f32 v22 v25 v26
v30 = to_i32 v29
v31 = mad_f32 v23 v25 v26
v32 = to_i32 v31
v33 = mad_f32 v24 v25 v26
v34 = to_i32 v33
v35 = pack v28 v30 8
v36 = pack v32 v34 8
v37 = pack v35 v36 16
store32 arg(1) v37
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r5 = mad_f32 r6 r10 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
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r5 = mad_f32 r5 r3 r4
r5 = to_i32 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
r8 = pack r7 r8 8
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r5 = pack r9 r5 8
r5 = pack r8 r5 16
store32 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 A8
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
17 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v0 = load8 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v2 = to_f32 v0
☠️ v3 = mul_f32 v1 v2
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v4 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v5 = splat 0 (0)
v6 = load8 arg(1)
v7 = to_f32 v6
v8 = mul_f32 v1 v7
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v9 = sub_f32 v4 v4
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v10 = mad_f32 v5 v9 v3
v11 = mad_f32 v8 v9 v4
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v12 = splat 437F0000 (255)
↑ v13 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v14 = mad_f32 v11 v12 v13
v15 = to_i32 v14
store8 arg(1) v15
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
22 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load8 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v2 = to_f32 v0
v3 = mul_f32 v1 v2
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v4 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v5 = load8 arg(1)
v6 = to_f32 v5
v7 = mul_f32 v1 v6
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v8 = sub_f32 v4 v4
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v9 = mad_f32 v7 v8 v3
☠️ v10 = mad_f32 v4 v8 v4
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v11 = splat 3E59B3D0 (0.21259999)
↑ v12 = splat 3F371759 (0.71520001)
↑ v13 = splat 3D93DD98 (0.0722)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v14 = mul_f32 v9 v13
v15 = mad_f32 v9 v12 v14
v16 = mad_f32 v9 v11 v15
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v17 = splat 437F0000 (255)
↑ v18 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v19 = mad_f32 v16 v17 v18
v20 = to_i32 v19
store8 arg(1) v20
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r8 = mad_f32 r9 r2 r8
r9 = mul_f32 r8 r5
r9 = mad_f32 r8 r4 r9
r9 = mad_f32 r8 r3 r9
r9 = mad_f32 r9 r6 r7
r9 = to_i32 r9
store8 arg(1) r9
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
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
38 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load8 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v2 = to_f32 v0
v3 = mul_f32 v1 v2
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v4 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v5 = load32 arg(1)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v6 = splat FF (3.5733111e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v7 = extract v5 0 v6
v8 = to_f32 v7
v9 = mul_f32 v1 v8
v10 = extract v5 8 v6
v11 = to_f32 v10
v12 = mul_f32 v1 v11
v13 = extract v5 16 v6
v14 = to_f32 v13
v15 = mul_f32 v1 v14
v16 = extract v5 24 v6
v17 = to_f32 v16
v18 = mul_f32 v1 v17
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v19 = sub_f32 v4 v4
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v20 = mad_f32 v9 v19 v3
v21 = mad_f32 v12 v19 v3
v22 = mad_f32 v15 v19 v3
v23 = mad_f32 v18 v19 v4
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v24 = splat 437F0000 (255)
↑ v25 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v26 = mad_f32 v20 v24 v25
v27 = to_i32 v26
v28 = mad_f32 v21 v24 v25
v29 = to_i32 v28
v30 = mad_f32 v22 v24 v25
v31 = to_i32 v30
v32 = mad_f32 v23 v24 v25
v33 = to_i32 v32
v34 = pack v27 v29 8
v35 = pack v31 v33 8
v36 = pack v34 v35 16
store32 arg(1) v36
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r6 = mad_f32 r10 r3 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
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r6 = mad_f32 r6 r4 r5
r6 = to_i32 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
r7 = mad_f32 r7 r4 r5
r7 = to_i32 r7
r9 = pack r8 r9 8
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r7 = pack r6 r7 8
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 = 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
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
30 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load32 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat FF (3.5733111e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v2 = extract v0 0 v1
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v3 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
☠️ v4 = to_f32 v2
☠️ v5 = mul_f32 v3 v4
☠️ v6 = extract v0 8 v1
☠️ v7 = to_f32 v6
☠️ v8 = mul_f32 v3 v7
☠️ v9 = extract v0 16 v1
☠️ v10 = to_f32 v9
☠️ v11 = mul_f32 v3 v10
v12 = extract v0 24 v1
v13 = to_f32 v12
v14 = mul_f32 v3 v13
☠️ v15 = splat 0 (0)
v16 = load8 arg(1)
v17 = to_f32 v16
v18 = mul_f32 v3 v17
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v19 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v20 = sub_f32 v19 v14
☠️ v21 = mad_f32 v15 v20 v5
☠️ v22 = mad_f32 v15 v20 v8
☠️ v23 = mad_f32 v15 v20 v11
v24 = mad_f32 v18 v20 v14
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v25 = splat 437F0000 (255)
↑ v26 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v27 = mad_f32 v24 v25 v26
v28 = to_i32 v27
store8 arg(1) v28
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r5 = mad_f32 r6 r7 r5
r5 = mad_f32 r5 r3 r4
r5 = to_i32 r5
store8 arg(1) 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
RGBA_8888 over G8
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
35 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load32 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat FF (3.5733111e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v2 = extract v0 0 v1
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v3 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v4 = to_f32 v2
v5 = mul_f32 v3 v4
v6 = extract v0 8 v1
v7 = to_f32 v6
v8 = mul_f32 v3 v7
v9 = extract v0 16 v1
v10 = to_f32 v9
v11 = mul_f32 v3 v10
v12 = extract v0 24 v1
v13 = to_f32 v12
v14 = mul_f32 v3 v13
v15 = load8 arg(1)
v16 = to_f32 v15
v17 = mul_f32 v3 v16
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v18 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v19 = sub_f32 v18 v14
v20 = mad_f32 v17 v19 v5
v21 = mad_f32 v17 v19 v8
v22 = mad_f32 v17 v19 v11
☠️ v23 = mad_f32 v18 v19 v14
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v24 = splat 3E59B3D0 (0.21259999)
↑ v25 = splat 3F371759 (0.71520001)
↑ v26 = splat 3D93DD98 (0.0722)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v27 = mul_f32 v22 v26
v28 = mad_f32 v21 v25 v27
v29 = mad_f32 v20 v24 v28
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v30 = splat 437F0000 (255)
↑ v31 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v32 = mad_f32 v29 v30 v31
v33 = to_i32 v32
store8 arg(1) v33
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r11 = mad_f32 r12 r8 r11
r11 = mul_f32 r11 r5
r11 = mad_f32 r10 r4 r11
r11 = mad_f32 r9 r3 r11
r11 = mad_f32 r11 r6 r7
r11 = to_i32 r11
store8 arg(1) r11
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
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
48 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load32 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat FF (3.5733111e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v2 = extract v0 0 v1
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v3 = splat 3B808081 (0.0039215689)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v4 = to_f32 v2
v5 = mul_f32 v3 v4
v6 = extract v0 8 v1
v7 = to_f32 v6
v8 = mul_f32 v3 v7
v9 = extract v0 16 v1
v10 = to_f32 v9
v11 = mul_f32 v3 v10
v12 = extract v0 24 v1
v13 = to_f32 v12
v14 = mul_f32 v3 v13
v15 = load32 arg(1)
v16 = extract v15 0 v1
v17 = to_f32 v16
v18 = mul_f32 v3 v17
v19 = extract v15 8 v1
v20 = to_f32 v19
v21 = mul_f32 v3 v20
v22 = extract v15 16 v1
v23 = to_f32 v22
v24 = mul_f32 v3 v23
v25 = extract v15 24 v1
v26 = to_f32 v25
v27 = mul_f32 v3 v26
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v28 = splat 3F800000 (1)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v29 = sub_f32 v28 v14
v30 = mad_f32 v18 v29 v5
v31 = mad_f32 v21 v29 v8
v32 = mad_f32 v24 v29 v11
v33 = mad_f32 v27 v29 v14
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v34 = splat 437F0000 (255)
↑ v35 = splat 3F000000 (0.5)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v36 = mad_f32 v30 v34 v35
v37 = to_i32 v36
v38 = mad_f32 v31 v34 v35
v39 = to_i32 v38
v40 = mad_f32 v32 v34 v35
v41 = to_i32 v40
v42 = mad_f32 v33 v34 v35
v43 = to_i32 v42
v44 = pack v37 v39 8
v45 = pack v41 v43 8
v46 = pack v44 v45 16
store32 arg(1) v46
add Builder::dump() I used to have a dump of the value program before it was translated to registers, but it went away a while ago. This restores it. Change-Id: I9b8bfcb124843cad4b0dc44bdf0a03e95a0c83d8 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/219757 Commit-Queue: Mike Klein <mtklein@google.com> Commit-Queue: Brian Osman <brianosman@google.com> Auto-Submit: Mike Klein <mtklein@google.com> Reviewed-by: Brian Osman <brianosman@google.com>
2019-06-10 17:05:48 +00:00
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
refactor to remove the need for death schedule This cuts the overhead bench from about 19µs to about 15µs. The key insight here is that the only registers that might become available after any given instruction are the ones that hold that instruction's inputs. We can check when they become available directly from the original Builder::Program, without needing a side death schedule data structure. Marking hoisted instructions as having life == program size helps make this logic a little simpler to reason through. Change-Id: Ifb9957f2d0e323e0e5d07996a2cc988f7c8b4c3f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223117 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-23 19:52:37 +00:00
r6 = mad_f32 r10 r13 r6
r7 = mad_f32 r11 r13 r7
r8 = mad_f32 r12 r13 r8
r5 = mad_f32 r9 r13 r5
r6 = mad_f32 r6 r3 r4
r6 = to_i32 r6
r7 = mad_f32 r7 r3 r4
r7 = to_i32 r7
r8 = mad_f32 r8 r3 r4
r8 = to_i32 r8
r5 = mad_f32 r5 r3 r4
r5 = to_i32 r5
r7 = pack r6 r7 8
r5 = pack r8 r5 8
r5 = pack r7 r5 16
store32 arg(1) 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
first VEX ymm vector ops - 32x8 i32 add,sub,mul - add I32_Naive bench/test builder to get better i32 mul coverage - minor refactoring all over Change-Id: I13cc19ff37a2da0bcff289ba51baac08f456d6c5 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222485 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-20 16:37:10 +00:00
I32 (Naive) 8888 over 8888
add misc. value programs to SkVMTest.expected Noticed we were only dumping the final register programs for the integer code. Might as well also track the value programs. Change-Id: I417c5c655b632691557bbbb136dcbd3f3167af9a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225324 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-07-02 20:39:23 +00:00
29 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load32 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat FF (3.5733111e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v2 = extract v0 0 v1
v3 = extract v0 8 v1
v4 = extract v0 16 v1
v5 = extract v0 24 v1
v6 = load32 arg(1)
v7 = extract v6 0 v1
v8 = extract v6 8 v1
v9 = extract v6 16 v1
v10 = extract v6 24 v1
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v11 = splat 100 (3.5873241e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v12 = sub_i32 v11 v5
v13 = mul_i32 v7 v12
v14 = shr v13 8
v15 = add_i32 v2 v14
v16 = mul_i32 v8 v12
v17 = shr v16 8
v18 = add_i32 v3 v17
v19 = mul_i32 v9 v12
v20 = shr v19 8
v21 = add_i32 v4 v20
v22 = mul_i32 v10 v12
v23 = shr v22 8
v24 = add_i32 v5 v23
v25 = pack v15 v18 8
v26 = pack v21 v24 8
v27 = pack v25 v26 16
store32 arg(1) v27
add misc. value programs to SkVMTest.expected Noticed we were only dumping the final register programs for the integer code. Might as well also track the value programs. Change-Id: I417c5c655b632691557bbbb136dcbd3f3167af9a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225324 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-07-02 20:39:23 +00:00
first VEX ymm vector ops - 32x8 i32 add,sub,mul - add I32_Naive bench/test builder to get better i32 mul coverage - minor refactoring all over Change-Id: I13cc19ff37a2da0bcff289ba51baac08f456d6c5 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/222485 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-20 16:37:10 +00:00
11 registers, 29 instructions:
r0 = splat FF (3.5733111e-43)
r1 = splat 100 (3.5873241e-43)
loop:
r2 = load32 arg(0)
r3 = extract r2 0 r0
r4 = extract r2 8 r0
r5 = extract r2 16 r0
r2 = extract r2 24 r0
r6 = load32 arg(1)
r7 = extract r6 0 r0
r8 = extract r6 8 r0
r9 = extract r6 16 r0
r6 = extract r6 24 r0
r10 = sub_i32 r1 r2
r7 = mul_i32 r7 r10
r7 = shr r7 8
r7 = add_i32 r3 r7
r8 = mul_i32 r8 r10
r8 = shr r8 8
r8 = add_i32 r4 r8
r9 = mul_i32 r9 r10
r9 = shr r9 8
r9 = add_i32 r5 r9
r10 = mul_i32 r6 r10
r10 = shr r10 8
r10 = add_i32 r2 r10
r8 = pack r7 r8 8
r10 = pack r9 r10 8
r10 = pack r8 r10 16
store32 arg(1) r10
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 misc. value programs to SkVMTest.expected Noticed we were only dumping the final register programs for the integer code. Might as well also track the value programs. Change-Id: I417c5c655b632691557bbbb136dcbd3f3167af9a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225324 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-07-02 20:39:23 +00:00
29 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load32 arg(0)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v1 = splat FF (3.5733111e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v2 = bit_and v0 v1
v3 = bytes v0 2
v4 = bytes v0 3
v5 = shr v0 24
v6 = load32 arg(1)
v7 = bit_and v6 v1
v8 = bytes v6 2
v9 = bytes v6 3
v10 = shr v6 24
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v11 = splat 100 (3.5873241e-43)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v12 = sub_i32 v11 v5
v13 = mul_i16x2 v7 v12
v14 = shr v13 8
v15 = add_i32 v2 v14
v16 = mul_i16x2 v8 v12
v17 = shr v16 8
v18 = add_i32 v3 v17
v19 = mul_i16x2 v9 v12
v20 = shr v19 8
v21 = add_i32 v4 v20
v22 = mul_i16x2 v10 v12
v23 = shr v22 8
v24 = add_i32 v5 v23
v25 = pack v15 v18 8
v26 = pack v21 v24 8
v27 = pack v25 v26 16
store32 arg(1) v27
add misc. value programs to SkVMTest.expected Noticed we were only dumping the final register programs for the integer code. Might as well also track the value programs. Change-Id: I417c5c655b632691557bbbb136dcbd3f3167af9a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225324 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-07-02 20:39:23 +00:00
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
11 registers, 29 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)
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r1 = splat 100 (3.5873241e-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:
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r2 = load32 arg(0)
proposed: add bytes() op I'm staring at this assembly, vmovups (%rsi), %ymm3 vpsrld $24, %ymm3, %ymm4 vpslld $16, %ymm4, %ymm15 vorps %ymm4, %ymm15, %ymm4 vpsubw %ymm4, %ymm0, %ymm4 Just knowing that could be vmovups (%rsi), %ymm3 vpshufb 0x??(%rip), %ymm3, %ymm4 vpsubw %ymm4, %ymm0, %ymm4 That is, instead of shifting, shifting, and bit-oring to create the 0a0a scale factor from ymm3, we could just byte shuffle directly using some pre-baked control pattern (stored at the end of the program like other constants) pshufb lets you arbitrarily remix bytes from its argument and zero bytes, and NEON has a similar family of vtbl instructions, even including that same feature of injecting zeroes. I think I've got this working, and the speedup is great, from 0.19 to 0.16 ns/px for I32_SWAR, and from 0.43 to 0.38 ns/px for I32. Change-Id: Iab850275e826b4187f0efc9495a4b9eab4402c38 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220871 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 21:43:18 +00:00
r3 = bit_and r2 r0
r4 = bytes r2 2
r5 = bytes r2 3
baby steps into 16-bit ops I figure the easiest way to expose 16-bit operations is to expose 16x2 pair operations... this means we can continue to always work with the same size vector. Switching from 32-bit multiplies to 16-bit multiplies is going to deliver the most oomph... they cost roughly half what 32-bit multiplies do on x86. Speed now: I32_SWAR: 0.27 ns/px I32: 0.43 ns/px F32: 0.76 ns/px RP: 0.8 ns/px Opts: 0.2 ns/px Change-Id: I8350c71722a9bde714ba18f97b8687fe35cc749f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220709 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 16:29:26 +00:00
r2 = shr r2 24
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r6 = load32 arg(1)
proposed: add bytes() op I'm staring at this assembly, vmovups (%rsi), %ymm3 vpsrld $24, %ymm3, %ymm4 vpslld $16, %ymm4, %ymm15 vorps %ymm4, %ymm15, %ymm4 vpsubw %ymm4, %ymm0, %ymm4 Just knowing that could be vmovups (%rsi), %ymm3 vpshufb 0x??(%rip), %ymm3, %ymm4 vpsubw %ymm4, %ymm0, %ymm4 That is, instead of shifting, shifting, and bit-oring to create the 0a0a scale factor from ymm3, we could just byte shuffle directly using some pre-baked control pattern (stored at the end of the program like other constants) pshufb lets you arbitrarily remix bytes from its argument and zero bytes, and NEON has a similar family of vtbl instructions, even including that same feature of injecting zeroes. I think I've got this working, and the speedup is great, from 0.19 to 0.16 ns/px for I32_SWAR, and from 0.43 to 0.38 ns/px for I32. Change-Id: Iab850275e826b4187f0efc9495a4b9eab4402c38 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220871 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 21:43:18 +00:00
r7 = bit_and r6 r0
r8 = bytes r6 2
r9 = bytes r6 3
baby steps into 16-bit ops I figure the easiest way to expose 16-bit operations is to expose 16x2 pair operations... this means we can continue to always work with the same size vector. Switching from 32-bit multiplies to 16-bit multiplies is going to deliver the most oomph... they cost roughly half what 32-bit multiplies do on x86. Speed now: I32_SWAR: 0.27 ns/px I32: 0.43 ns/px F32: 0.76 ns/px RP: 0.8 ns/px Opts: 0.2 ns/px Change-Id: I8350c71722a9bde714ba18f97b8687fe35cc749f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220709 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 16:29:26 +00:00
r6 = shr r6 24
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r10 = sub_i32 r1 r2
baby steps into 16-bit ops I figure the easiest way to expose 16-bit operations is to expose 16x2 pair operations... this means we can continue to always work with the same size vector. Switching from 32-bit multiplies to 16-bit multiplies is going to deliver the most oomph... they cost roughly half what 32-bit multiplies do on x86. Speed now: I32_SWAR: 0.27 ns/px I32: 0.43 ns/px F32: 0.76 ns/px RP: 0.8 ns/px Opts: 0.2 ns/px Change-Id: I8350c71722a9bde714ba18f97b8687fe35cc749f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220709 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 16:29:26 +00:00
r7 = mul_i16x2 r7 r10
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r7 = shr r7 8
r7 = add_i32 r3 r7
baby steps into 16-bit ops I figure the easiest way to expose 16-bit operations is to expose 16x2 pair operations... this means we can continue to always work with the same size vector. Switching from 32-bit multiplies to 16-bit multiplies is going to deliver the most oomph... they cost roughly half what 32-bit multiplies do on x86. Speed now: I32_SWAR: 0.27 ns/px I32: 0.43 ns/px F32: 0.76 ns/px RP: 0.8 ns/px Opts: 0.2 ns/px Change-Id: I8350c71722a9bde714ba18f97b8687fe35cc749f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220709 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 16:29:26 +00:00
r8 = mul_i16x2 r8 r10
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r8 = shr r8 8
r8 = add_i32 r4 r8
baby steps into 16-bit ops I figure the easiest way to expose 16-bit operations is to expose 16x2 pair operations... this means we can continue to always work with the same size vector. Switching from 32-bit multiplies to 16-bit multiplies is going to deliver the most oomph... they cost roughly half what 32-bit multiplies do on x86. Speed now: I32_SWAR: 0.27 ns/px I32: 0.43 ns/px F32: 0.76 ns/px RP: 0.8 ns/px Opts: 0.2 ns/px Change-Id: I8350c71722a9bde714ba18f97b8687fe35cc749f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220709 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 16:29:26 +00:00
r9 = mul_i16x2 r9 r10
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r9 = shr r9 8
r9 = add_i32 r5 r9
baby steps into 16-bit ops I figure the easiest way to expose 16-bit operations is to expose 16x2 pair operations... this means we can continue to always work with the same size vector. Switching from 32-bit multiplies to 16-bit multiplies is going to deliver the most oomph... they cost roughly half what 32-bit multiplies do on x86. Speed now: I32_SWAR: 0.27 ns/px I32: 0.43 ns/px F32: 0.76 ns/px RP: 0.8 ns/px Opts: 0.2 ns/px Change-Id: I8350c71722a9bde714ba18f97b8687fe35cc749f Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220709 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 16:29:26 +00:00
r10 = mul_i16x2 r6 r10
remove mul_unorm8/mad_unorm8 I just kind of remembered that if we're doing (xy+x)/256 and x is a destination channel and y is 255-sa, then you can get the +x for free by multiplying by 256-sa instead. (d * (255-sa) + d) (d * (255-sa + 1)) (d * (256-sa) ) Duh. This is a trick we play in a lot of legacy code and I've just now realized it's exactly equivalent to the trick I want to play here... sigh. Folding this math in kind of makes mul/mad_unorm8 moot. Speed's getting good: I32_SWAR: 0.3 ns/px I32 : 0.55 ns/px F32 : 0.8 ns/px RP : 0.8 ns/px Opts : 0.2 ns/px Change-Id: I4d10db51ea80a3258c36e97b6b334ad253804613 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220708 Reviewed-by: Herb Derby <herb@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 15:56:51 +00:00
r10 = shr r10 8
r10 = add_i32 r2 r10
r8 = pack r7 r8 8
r10 = pack r9 r10 8
r10 = pack r8 r10 16
store32 arg(1) r10
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
add misc. value programs to SkVMTest.expected Noticed we were only dumping the final register programs for the integer code. Might as well also track the value programs. Change-Id: I417c5c655b632691557bbbb136dcbd3f3167af9a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225324 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-07-02 20:39:23 +00:00
15 values:
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v0 = load32 arg(0)
v1 = bytes v0 404
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v2 = splat 1000100 (2.3510604e-38)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v3 = sub_i16x2 v2 v1
v4 = load32 arg(1)
move hoist analysis back into Builder Even if a JIT ultimately doesn't end up hoisting any values, it's going to want this information while it decides. Writing it in one place also ensures we only get it wrong in one place... I'm no_ extending the lifetime of hoisted instructions here in Builder. That's something to leave to the backend so they have the flexibility of which of these values to hoist, if any. If they don't hoist, they'll need to know when the value dies. Moving this information back here lets the test expectation goldens reflect the hoist bit again too. Kind of nice. Change-Id: Ib165ca898a97c1d822cb28fe24f15bae4d570a17 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/229024 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-07-22 18:44:54 +00:00
↑ v5 = splat FF00FF (2.3418409e-38)
split deaths() out of other analysis I'm slowly refactoring my way to where hoisting and register assignment are done in backend-specific ways, but this liveness analysis is always going to be useful for each backend. Use deaths() to restore friendly ☠️ dead code markers in test dumps. Change-Id: I3ab94665bbbbf0788b0b27e00d644eba927dff47 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/228113 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Mike Klein <mtklein@google.com>
2019-07-17 17:09:09 +00:00
v6 = bit_and v4 v5
v7 = shr_i16x2 v4 8
v8 = mul_i16x2 v6 v3
v9 = shr_i16x2 v8 8
v10 = mul_i16x2 v7 v3
v11 = bit_clear v10 v5
v12 = bit_or v9 v11
v13 = add_i32 v0 v12
store32 arg(1) v13
add misc. value programs to SkVMTest.expected Noticed we were only dumping the final register programs for the integer code. Might as well also track the value programs. Change-Id: I417c5c655b632691557bbbb136dcbd3f3167af9a Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225324 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-07-02 20:39:23 +00:00
add bit_clear I was just reading the ARM docs and realized that their BIC ("BIt Clear") is the same as SSE's ANDN ("AND Not") instruction. It's kind of a neat little tool to have laying around... comes up more than you'd think, and it's sometimes the clearest way to express what you're doing, as in the changed program here where the comment is "mask away the low bits". That's a bit_clear with a mask for what you want to clear away! And the real reason to write this up is that I want to have a CL to point to that shows how to add an instruction top to bottom. Change-Id: I99690ed9c1009427b3986955e7ae6264de4d215c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223120 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-06-24 00:35:28 +00:00
6 registers, 15 instructions:
streamline srcover math in I32_SWAR This is the final bunny I've got in my hat, I think... Remembering that none of the s += d*invA adds can overflow, we can use a single 32-bit add to add them all at once. This means we don't have to unpack the src pixel into rb/ga halves. We need only extract the alpha for invA. This brings I32_SWAR even with the Opts code! curr/maxrss loops min median mean max stddev samples config bench 36/36 MB 133 0.206ns 0.211ns 0.208ns 0.211ns 1% ▁▇▁█▁▇▁▇▁▇ nonrendering SkVM_4096_I32_SWAR 37/37 MB 152 0.432ns 0.432ns 0.434ns 0.444ns 1% ▃▁▁▁▁▃▁▁█▁ nonrendering SkVM_4096_I32 37/37 MB 50 0.781ns 0.794ns 0.815ns 0.895ns 5% ▆▂█▃▅▂▂▁▂▁ nonrendering SkVM_4096_F32 37/37 MB 76 0.773ns 0.78ns 0.804ns 0.907ns 6% ▄█▅▁▁▁▁▂▁▁ nonrendering SkVM_4096_RP 37/37 MB 268 0.201ns 0.203ns 0.203ns 0.204ns 0% █▇▆▆▆▆▁▆▆▆ nonrendering SkVM_4096_Opts Change-Id: Ibf0a9c5d90b35f1e9cf7265868bd18b7e0a76c43 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220805 Reviewed-by: Mike Klein <mtklein@google.com> Commit-Queue: Mike Klein <mtklein@google.com>
2019-06-13 18:12:38 +00:00
r0 = splat 1000100 (2.3510604e-38)
r1 = splat FF00FF (2.3418409e-38)
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:
add bit_clear I was just reading the ARM docs and realized that their BIC ("BIt Clear") is the same as SSE's ANDN ("AND Not") instruction. It's kind of a neat little tool to have laying around... comes up more than you'd think, and it's sometimes the clearest way to express what you're doing, as in the changed program here where the comment is "mask away the low bits". That's a bit_clear with a mask for what you want to clear away! And the real reason to write this up is that I want to have a CL to point to that shows how to add an instruction top to bottom. Change-Id: I99690ed9c1009427b3986955e7ae6264de4d215c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223120 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-06-24 00:35:28 +00:00
r2 = load32 arg(0)
r3 = bytes r2 404
r3 = sub_i16x2 r0 r3
r4 = load32 arg(1)
r5 = bit_and r4 r1
r4 = shr_i16x2 r4 8
r5 = mul_i16x2 r5 r3
trim another instruction of I32_SWAR Now that we've got shr_16x2, extract(..., 8, splat(0x00ff00ff)) is better done as shr_16x2(..., 8). This swaps a 16-bit shift in for the 32-bit shift, a wash, but lets us drop the bit_and at the end, saving one whole instruction. This places I32_SWAR a tiny little bit faster than the code in Opts, like .19 ns/px vs .20 ns/px for Opts. Change-Id: I4160dc03ecc8b855c0773a927f1510ad5cbb4b87 Reviewed-on: https://skia-review.googlesource.com/c/skia/+/220856 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com>
2019-06-13 20:51:39 +00:00
r5 = shr_i16x2 r5 8
add bit_clear I was just reading the ARM docs and realized that their BIC ("BIt Clear") is the same as SSE's ANDN ("AND Not") instruction. It's kind of a neat little tool to have laying around... comes up more than you'd think, and it's sometimes the clearest way to express what you're doing, as in the changed program here where the comment is "mask away the low bits". That's a bit_clear with a mask for what you want to clear away! And the real reason to write this up is that I want to have a CL to point to that shows how to add an instruction top to bottom. Change-Id: I99690ed9c1009427b3986955e7ae6264de4d215c Reviewed-on: https://skia-review.googlesource.com/c/skia/+/223120 Commit-Queue: Mike Klein <mtklein@google.com> Reviewed-by: Herb Derby <herb@google.com> Reviewed-by: Mike Reed <reed@google.com>
2019-06-24 00:35:28 +00:00
r3 = mul_i16x2 r4 r3
r3 = bit_clear r3 r1
r3 = bit_or r5 r3
r3 = add_i32 r2 r3
store32 arg(1) r3
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