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