Hi, This message is probably mainly targeted at Tom, but since we have a mailing list and other people may be interested, I thought I'd send it to everyone. I was looking at compiled bytecode, and I noticed things that might be able to be improved - in rough order of difficulty. I don't think any of these impact on the backend at all, but might make faster code in general. == 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... == 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
== 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
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.
-bcodeflatten is precisely the bytecode that the compiler outputs ... <from Compile.lhs> pF (sBcodeFlatten flags) "BCode after flattening:" (strBCode (strISBC state) bcode) {- Convert to relative jumps -} bcode <- return (bcRelative bcode) pF (sBcodeRel flags) "BCode after relativising" (strBCode (strISBC state) bcode) {- Write to file -} bcWrite state flags fileflags bcode The only stage after flattening is relativisation, which involves converting for absolute to relative jumps and converting instructions to bytecodes (e.g. PUSH 0 might become 0x42). The reason you won't find unconditional jumps in the flattened output is because flattening removes almost all unconditional jumps (they're usually unnecessary). It is hard to understand though because it's optimized away a lot of normal jump structures, making the flow of control much more subtle. Cheers :-) Tom
participants (2)
-
Neil Mitchell -
shackell＠cs.york.ac.uk