2021-11-15 13:46:50 +00:00
|
|
|
$0 = u1[0] (float, L3)
|
|
|
|
|
$1 = u1[1] (float, L3)
|
|
|
|
|
$2 = u1[2] (float, L3)
|
|
|
|
|
$3 = u1[3] (float, L3)
|
|
|
|
|
$4 = u2[0] (float, L8)
|
|
|
|
|
$5 = u2[1] (float, L8)
|
|
|
|
|
$6 = u2[2] (float, L8)
|
|
|
|
|
$7 = u2[3] (float, L8)
|
|
|
|
|
$8 = u3[0] (float, L17)
|
|
|
|
|
$9 = u3[1] (float, L17)
|
|
|
|
|
$10 = u3[2] (float, L17)
|
|
|
|
|
$11 = u3[3] (float, L17)
|
|
|
|
|
$12 = u4[0] (float, L26)
|
|
|
|
|
$13 = u4[1] (float, L26)
|
|
|
|
|
$14 = u4[2] (float, L26)
|
|
|
|
|
$15 = u4[3] (float, L26)
|
|
|
|
|
$16 = u4[4] (float, L26)
|
|
|
|
|
$17 = u4[5] (float, L26)
|
|
|
|
|
$18 = u4[6] (float, L26)
|
|
|
|
|
$19 = u4[7] (float, L26)
|
|
|
|
|
$20 = u4[8] (float, L26)
|
|
|
|
|
$21 = u4[9] (float, L26)
|
|
|
|
|
$22 = u4[10] (float, L26)
|
|
|
|
|
$23 = u4[11] (float, L26)
|
|
|
|
|
$24 = u4[12] (float, L26)
|
|
|
|
|
$25 = u4[13] (float, L26)
|
|
|
|
|
$26 = u4[14] (float, L26)
|
|
|
|
|
$27 = u4[15] (float, L26)
|
|
|
|
|
$28 = xy (float2 : slot 1/2, L37)
|
|
|
|
|
$29 = xy (float2 : slot 2/2, L37)
|
|
|
|
|
$30 = sum (float, L10)
|
|
|
|
|
$31 = i (int, L11)
|
|
|
|
|
$32 = prod (float, L19)
|
|
|
|
|
$33 = i (int, L20)
|
|
|
|
|
$34 = sum (float, L28)
|
|
|
|
|
$35 = f (float, L29)
|
2021-11-17 21:12:29 +00:00
|
|
|
F0 = float4 main(float2 xy)
|
|
|
|
|
F1 = float index_by_literal()
|
|
|
|
|
F2 = float index_by_loop()
|
|
|
|
|
F3 = float index_by_complex_loop()
|
|
|
|
|
F4 = float index_out_of_bounds_checked()
|
2021-11-15 13:46:50 +00:00
|
|
|
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
54 registers, 171 instructions:
|
2021-11-29 20:36:01 +00:00
|
|
|
0 r0 = uniform32 ptr0 0
|
|
|
|
|
1 r1 = uniform32 ptr0 4
|
|
|
|
|
2 r2 = uniform32 ptr0 8
|
|
|
|
|
3 r3 = uniform32 ptr0 C
|
|
|
|
|
4 r4 = uniform32 ptr0 10
|
|
|
|
|
5 r5 = uniform32 ptr0 14
|
|
|
|
|
6 r6 = uniform32 ptr0 18
|
|
|
|
|
7 r7 = uniform32 ptr0 1C
|
|
|
|
|
8 r8 = uniform32 ptr0 20
|
|
|
|
|
9 r9 = uniform32 ptr0 24
|
|
|
|
|
10 r10 = uniform32 ptr0 28
|
|
|
|
|
11 r11 = uniform32 ptr0 2C
|
|
|
|
|
12 r12 = uniform32 ptr0 30
|
|
|
|
|
13 r13 = uniform32 ptr0 34
|
|
|
|
|
14 r14 = uniform32 ptr0 38
|
|
|
|
|
15 r15 = uniform32 ptr0 3C
|
|
|
|
|
16 r16 = uniform32 ptr0 40
|
|
|
|
|
17 r17 = uniform32 ptr0 44
|
|
|
|
|
18 r18 = uniform32 ptr0 48
|
|
|
|
|
19 r19 = uniform32 ptr0 4C
|
|
|
|
|
20 r20 = uniform32 ptr0 50
|
|
|
|
|
21 r21 = uniform32 ptr0 54
|
|
|
|
|
22 r22 = uniform32 ptr0 58
|
|
|
|
|
23 r23 = uniform32 ptr0 5C
|
|
|
|
|
24 r24 = uniform32 ptr0 60
|
|
|
|
|
25 r25 = uniform32 ptr0 64
|
|
|
|
|
26 r26 = uniform32 ptr0 68
|
|
|
|
|
27 r27 = uniform32 ptr0 6C
|
|
|
|
|
28 r28 = uniform32 ptr0 70
|
|
|
|
|
29 r29 = splat 0 (0)
|
|
|
|
|
30 r30 = splat 3F000000 (0.5)
|
|
|
|
|
31 r31 = eq_f32 r0 r30
|
2021-11-17 21:17:25 +00:00
|
|
|
32 r32 = splat 3 (4.2038954e-45)
|
|
|
|
|
33 r33 = splat 2 (2.8025969e-45)
|
2021-11-29 20:36:01 +00:00
|
|
|
34 r34 = add_f32 r7 r8
|
2021-11-17 21:17:25 +00:00
|
|
|
35 r35 = splat 1 (1.4012985e-45)
|
2021-11-29 20:36:01 +00:00
|
|
|
36 r36 = add_f32 r6 r34
|
|
|
|
|
37 r37 = add_f32 r5 r36
|
2021-11-17 21:17:25 +00:00
|
|
|
38 r38 = splat 3F800000 (1)
|
2021-11-29 20:36:01 +00:00
|
|
|
39 r39 = mul_f32 r9 r9
|
|
|
|
|
40 r40 = mul_f32 r11 r39
|
|
|
|
|
41 r41 = mul_f32 r12 r40
|
2021-11-17 21:17:25 +00:00
|
|
|
42 r42 = splat C0133333 (-2.3)
|
|
|
|
|
43 r43 = splat 3FB33334 (1.4000001)
|
2021-11-29 20:36:01 +00:00
|
|
|
44 r44 = sub_f32 r29 r14
|
2021-11-17 21:17:25 +00:00
|
|
|
45 r45 = splat 40A33334 (5.1000004)
|
2021-11-29 20:36:01 +00:00
|
|
|
46 r46 = sub_f32 r44 r18
|
2021-11-17 21:17:25 +00:00
|
|
|
47 r47 = splat 410CCCCD (8.8000002)
|
2021-11-29 20:36:01 +00:00
|
|
|
48 r48 = sub_f32 r46 r21
|
2021-11-17 21:17:25 +00:00
|
|
|
49 r49 = splat 41480000 (12.5)
|
2021-11-29 20:36:01 +00:00
|
|
|
50 r50 = sub_f32 r48 r25
|
2021-11-17 21:17:25 +00:00
|
|
|
51 r51 = splat 4181999A (16.200001)
|
2021-01-19 21:33:11 +00:00
|
|
|
loop:
|
2021-11-17 21:17:25 +00:00
|
|
|
52 r52 = index
|
2021-11-29 20:36:01 +00:00
|
|
|
53 r53 = eq_f32 r52 r30
|
2021-11-24 19:16:32 +00:00
|
|
|
54 r53 = bit_and r53 r31
|
2021-11-29 20:36:01 +00:00
|
|
|
55 trace_var r53 $0 = r1
|
|
|
|
|
56 trace_var r53 $1 = r2
|
|
|
|
|
57 trace_var r53 $2 = r3
|
|
|
|
|
58 trace_var r53 $3 = r4
|
|
|
|
|
59 trace_var r53 $4 = r5
|
|
|
|
|
60 trace_var r53 $5 = r6
|
|
|
|
|
61 trace_var r53 $6 = r7
|
|
|
|
|
62 trace_var r53 $7 = r8
|
|
|
|
|
63 trace_var r53 $8 = r9
|
|
|
|
|
64 trace_var r53 $9 = r10
|
|
|
|
|
65 trace_var r53 $10 = r11
|
|
|
|
|
66 trace_var r53 $11 = r12
|
|
|
|
|
67 trace_var r53 $12 = r13
|
|
|
|
|
68 trace_var r53 $13 = r14
|
|
|
|
|
69 trace_var r53 $14 = r15
|
|
|
|
|
70 trace_var r53 $15 = r16
|
|
|
|
|
71 trace_var r53 $16 = r17
|
|
|
|
|
72 trace_var r53 $17 = r18
|
|
|
|
|
73 trace_var r53 $18 = r19
|
|
|
|
|
74 trace_var r53 $19 = r20
|
|
|
|
|
75 trace_var r53 $20 = r21
|
|
|
|
|
76 trace_var r53 $21 = r22
|
|
|
|
|
77 trace_var r53 $22 = r23
|
|
|
|
|
78 trace_var r53 $23 = r24
|
|
|
|
|
79 trace_var r53 $24 = r25
|
|
|
|
|
80 trace_var r53 $25 = r26
|
|
|
|
|
81 trace_var r53 $26 = r27
|
|
|
|
|
82 trace_var r53 $27 = r28
|
2021-11-29 15:07:22 +00:00
|
|
|
83 trace_enter r53 F0
|
2021-11-20 01:01:44 +00:00
|
|
|
84 trace_var r53 $28 = r52
|
2021-11-29 20:36:01 +00:00
|
|
|
85 trace_var r53 $29 = r0
|
2021-11-17 21:17:25 +00:00
|
|
|
86 trace_line r53 L38
|
2021-11-29 15:07:22 +00:00
|
|
|
87 trace_enter r53 F1
|
2021-11-17 21:17:25 +00:00
|
|
|
88 trace_line r53 L5
|
2021-11-29 15:07:22 +00:00
|
|
|
89 trace_exit r53 F1
|
|
|
|
|
90 trace_enter r53 F2
|
2021-11-17 21:17:25 +00:00
|
|
|
91 trace_line r53 L10
|
2021-11-29 20:36:01 +00:00
|
|
|
92 trace_var r53 $30 = r29
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
93 trace_line r53 L11
|
2021-11-20 01:01:44 +00:00
|
|
|
94 trace_var r53 $31 = r32
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
95 trace_line r53 L12
|
2021-11-29 20:36:01 +00:00
|
|
|
96 trace_var r53 $30 = r8
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
97 trace_line r53 L11
|
2021-11-20 01:01:44 +00:00
|
|
|
98 trace_var r53 $31 = r33
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
99 trace_line r53 L12
|
2021-11-20 01:01:44 +00:00
|
|
|
100 trace_var r53 $30 = r34
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
101 trace_line r53 L11
|
2021-11-20 01:01:44 +00:00
|
|
|
102 trace_var r53 $31 = r35
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
103 trace_line r53 L12
|
2021-11-20 01:01:44 +00:00
|
|
|
104 trace_var r53 $30 = r36
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
105 trace_line r53 L11
|
2021-11-29 20:36:01 +00:00
|
|
|
106 trace_var r53 $31 = r29
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
107 trace_line r53 L12
|
2021-11-20 01:01:44 +00:00
|
|
|
108 trace_var r53 $30 = r37
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
109 trace_line r53 L11
|
|
|
|
|
110 trace_line r53 L14
|
2021-11-29 15:07:22 +00:00
|
|
|
111 trace_exit r53 F2
|
|
|
|
|
112 trace_enter r53 F3
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
113 trace_line r53 L19
|
2021-11-20 01:01:44 +00:00
|
|
|
114 trace_var r53 $32 = r38
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
115 trace_line r53 L20
|
2021-11-29 20:36:01 +00:00
|
|
|
116 trace_var r53 $33 = r29
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
117 trace_line r53 L21
|
2021-11-29 20:36:01 +00:00
|
|
|
118 trace_var r53 $32 = r9
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
119 trace_line r53 L20
|
2021-11-20 01:01:44 +00:00
|
|
|
120 trace_var r53 $33 = r35
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
121 trace_line r53 L21
|
2021-11-20 01:01:44 +00:00
|
|
|
122 trace_var r53 $32 = r39
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
123 trace_line r53 L20
|
2021-11-20 01:01:44 +00:00
|
|
|
124 trace_var r53 $33 = r33
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
125 trace_line r53 L21
|
2021-11-20 01:01:44 +00:00
|
|
|
126 trace_var r53 $32 = r40
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
127 trace_line r53 L20
|
2021-11-20 01:01:44 +00:00
|
|
|
128 trace_var r53 $33 = r32
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
129 trace_line r53 L21
|
2021-11-20 01:01:44 +00:00
|
|
|
130 trace_var r53 $32 = r41
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
131 trace_line r53 L20
|
|
|
|
|
132 trace_line r53 L23
|
2021-11-29 15:07:22 +00:00
|
|
|
133 trace_exit r53 F3
|
|
|
|
|
134 trace_enter r53 F4
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
135 trace_line r53 L28
|
2021-11-29 20:36:01 +00:00
|
|
|
136 trace_var r53 $34 = r29
|
2021-11-17 21:17:25 +00:00
|
|
|
137 trace_line r53 L29
|
2021-11-20 01:01:44 +00:00
|
|
|
138 trace_var r53 $35 = r42
|
2021-11-17 21:17:25 +00:00
|
|
|
139 trace_line r53 L30
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
140 trace_line r53 L29
|
2021-11-20 01:01:44 +00:00
|
|
|
141 trace_var r53 $35 = r43
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
142 trace_line r53 L30
|
|
|
|
|
143 trace_line r53 L31
|
2021-11-20 01:01:44 +00:00
|
|
|
144 trace_var r53 $34 = r44
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
145 trace_line r53 L29
|
2021-11-20 01:01:44 +00:00
|
|
|
146 trace_var r53 $35 = r45
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
147 trace_line r53 L30
|
|
|
|
|
148 trace_line r53 L31
|
2021-11-20 01:01:44 +00:00
|
|
|
149 trace_var r53 $34 = r46
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
150 trace_line r53 L29
|
2021-11-20 01:01:44 +00:00
|
|
|
151 trace_var r53 $35 = r47
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
152 trace_line r53 L30
|
|
|
|
|
153 trace_line r53 L31
|
2021-11-20 01:01:44 +00:00
|
|
|
154 trace_var r53 $34 = r48
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
155 trace_line r53 L29
|
2021-11-20 01:01:44 +00:00
|
|
|
156 trace_var r53 $35 = r49
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
157 trace_line r53 L30
|
|
|
|
|
158 trace_line r53 L31
|
2021-11-20 01:01:44 +00:00
|
|
|
159 trace_var r53 $34 = r50
|
2021-11-17 21:17:25 +00:00
|
|
|
160 trace_line r53 L29
|
2021-11-20 01:01:44 +00:00
|
|
|
161 trace_var r53 $35 = r51
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
162 trace_line r53 L30
|
|
|
|
|
163 trace_line r53 L29
|
|
|
|
|
164 trace_line r53 L34
|
2021-11-29 15:07:22 +00:00
|
|
|
165 trace_exit r53 F4
|
|
|
|
|
166 trace_exit r53 F0
|
2021-11-29 20:36:01 +00:00
|
|
|
167 store32 ptr1 r1
|
Improve redundant trace_var elimination.
Previously, we would avoid emitting redundant trace_vars by checking to
see if the slot is being assigned to the exact same Var.ID. However,
this had the potential to eliminate useful trace_vars:
- At the start of execution, slots all contain 0. Code which explicitly
assigned a zero into a slot would not be shown in a trace. (So things
like `color = half4(0,1,0,1)` would only emit traces for color.ga.)
- A function call's parameter slots are reused every time it is called,
so calling a function twice would only emit traces for the parameters
that aren't the same Val.ID as the previous call.
- A VarDeclaration inside a loop reuses its slot each time through the
loop, even though conceptually it's a "new" variable.
We now track a slot's "written-to" status. At the start of execution,
no slots have been "written-to". These slots will always emit a
trace_var opcode (fixing the first issue). Also, issuing a function
call or declaring a variable will reset the "written-to" status of the
associated slots (fixing the second and third issues).
When the debugger is not in use, the written-to field is unused.
Change-Id: I482a86cb6e90d0f85dd2a161e984f212782a7b4d
Bug: skia:12614
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/473776
Commit-Queue: John Stiles <johnstiles@google.com>
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
2021-11-18 21:36:29 +00:00
|
|
|
168 store32 ptr2 r37
|
|
|
|
|
169 store32 ptr3 r41
|
|
|
|
|
170 store32 ptr4 r50
|
