11:49 <alyssa> urjaman: Hah!

13:19 <alyssa> Trying to get back to 0 regressions after adding in the conditional reordering and load/store pairing stuff

13:19 <alyssa> Then we'll do another cycle of this -- rebase everything nicely, add a new feature (ALU bundling, I think), get to zero regressions

13:20 <alyssa> Next cycle after that will be constant combining (which is something we did on the old scheduler but will be more effective on the new one)

13:20 <alyssa> Oh and a cycle for writeout optimization

13:20 <alyssa> At that point, we'll be at feature parity with the old scheduler, the codegen itself will be marginally better than the old one

13:21 <alyssa> So that'll get reviewed and landed

13:21 <alyssa> At that point, all of the infrastructure for out-of-order scheduling will be in place

13:21 <alyssa> And that's when the fun begins and we can start experimenting with algorithms to minimize register pressure

13:21 <alyssa> I'm getting way ahead of myself, but that's the outline :)

13:26 <robmur01> so the out-of-order-scheduler schedule is in-order, but speculative?

17:49 <alyssa> robmur01: Right now it's still in-order

17:50 <alyssa> except for hoisting ld/st and delaying conditions

17:50 <alyssa> This is all just to prepare for being able to do out-of-order scheduling

17:50 <alyssa> i.e. making the dep graph explicit instead of relying on the order in the original source being unqiue

17:52 <robmur01> But I was talking about the preparation itself :P

17:53 <robmur01> if the plan was flexible we might have an out-of-order out-of-order-scheduler schedule, and who wants that? :D

18:12 <alyssa> So yes, I suppose it is in-order but speculative :p

18:27 <alyssa> SDKLJHFgj adgefhl.ruewhgofw

18:27 <alyssa> ball/bany do NOT replicate

18:27 <alyssa> learned that the hard way :V

18:32 <alyssa> Alright. Well then.

18:32 <alyssa> Now that that's handled, I think we might be clear with regressions from the "move conditionals" stuff