#14644: Improve cmm/assembly for pattern matches with two constants. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | Keywords: Codegen, CMM, Resolution: | Patterns, Pattern Matching Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:3 svenpanne]:
I am not sure if things are that easy: To do these kind of switches in a really good way, one would need a probability distribution how often the individual cases actually happen.
Additional things to consider: Performance in tight loops is often vastly different, because branch prediction/caching will most likely kick in visibly. Correctly predicted branches will cost you almost nothing, while unknown/incorrectly predicted branches will be much more costly. In
This is by no means meant as a "this is optimal" idea. As far as I'm aware there is currently no way to propagate probabilities through GHC's various stages. So even in cases where we can make a judgement on the probability we can't really use it at the Cmm level. In the end I suggested it because it: * I think it has a good chance of being faster * Leads to smaller code * Seems to be what gcc/clang do (using conditional moves instead of jumps but still). the absence of more information from their branch predictor, quite a few processors assume that backward branches are taken and forward branches are assumed to be not taken. So code layout has a non-trivial performance impact.
Instruction counts are quite misleading nowadays...
Indeed :( -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14644#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler