|
00:48
rurban joined
01:30
colomon joined
01:40
sivoais joined
02:13
zakharyas joined
02:25
kjs_ joined
08:41
rurban joined
09:49
FROGGS joined
10:01
LLamaRider joined
10:07
LLamaRider joined
10:25
LLamaRider joined
10:26
LLamaRider joined
10:27
LLamaRider joined
10:28
LLamaRider joined
10:32
LLamaRider joined
10:48
LLamaRider joined
|
|||
| JimmyZ | jnthn: I want to change the function used in optimize_bb returns enum { RETRY_OPTIMIZE; NEXT }, so the loop in opitmize_bb could retry optimization in case current ins changed by some optimization functions | 12:02 | |
| jnthn | But we can already do that by putting "continue;" after the function call? | 12:11 | |
| Oh, though we need to know if anything changed, I guess. | 12:12 | ||
| Alternatively, various optimizations do already, I think, make calls to optimize further what they just did | 12:13 | ||
| And that seems to have worked OK for us so far. | 12:15 | ||
| JimmyZ | well, some function may change current ins to one of several another ins, and some function(out of optimize.c) will too. if we just make calls to optimize_OP function, we need to be very careful about what ins it will be changed to. | 12:28 | |
| But just retry optimization in the loop in optimize_bb will be simpler. | 12:29 | ||
|
12:32
Ven joined
|
|||
| JimmyZ | like REPR(facts->type)->spesh | 12:32 | |
|
13:35
Ven joined
13:46
zakharyas joined
13:55
ggoebel111111117 joined
14:00
kjs_ joined
14:10
ggoebel111111117 joined
|
|||
| JimmyZ | i.e: return retry_optimize if current op changed and then go to back 'switch (ins)' is better than judging ins that is optimized to SET op verywhere and then call optimize_set | 14:40 | |
|
15:32
Ven joined
15:37
kjs_ joined
15:50
kjs_ joined
16:13
zakharyas joined
17:01
rurban joined
17:28
btyler joined
17:29
kjs_ joined
18:12
oetiker_ joined
18:13
FROGGS_ joined
18:23
colomon joined
19:01
Ven joined
20:13
kjs_ joined
22:01
btyler_ joined,
Util_ joined
22:46
kjs_ joined
|
|||