> == SLIDE 0 == > I noticed some of these, I take it they are a noop? If so, lets > peephole them away! Probably one line of code...
Woops, I was doing -bcodecompile, I notice that peepholing is done after that. I also notice that eval; jump; return is correctly flattened. The other two points still apply I think, particularly JUMP_FALSE. It would be useful to have documentation somewhere on what each of the debug flags does. I also can't find a debug flag that prints out the bytecode pretty much as the compiler generates, which is unfortunate. Also -bcodeflatten shows the flattened output, but doesn't include non-conditional jumps, which makes figuring out what is going on impossible. Thanks Neil > > == JUMP_FALSE -> JUMP_ZERO == > If we moved from JUMP_FALSE to JUMP_ZERO (which i take it is the same > semantics anyway!) then this could often be used for case statements > on two constructors (say lists, for example). Also case on a bool is > expanded to a case, if we had JUMP_ZERO this could be collapsed back > as a more general transformation. Less code, faster code, happier > code. > > == EVAL; JUMP; RETURN == > I noticed a few things that EVAL, then JUMP, then RETURN - of course > you could collapse the EVAL to EVAL_RETURN and throw away the jump. > Less code, more speed, everyone is happy :) > > == branch factorisation == > I noticed a few cases where two branches both jump to the same place, > and execute the same code, but the code before the jump's are the > same. These could be factorised into the after the jump bit - less > code, same speed, there are possibly more important things before > worrying about this... > > Thanks > > Neil > _______________________________________________ Yhc mailing list [email protected] http://haskell.org/mailman/listinfo/yhc
