#9246: GHC generates poor code for repeated uses of min/max --------------------------------------------+------------------------------ Reporter: arotenberg | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #6135 --------------------------------------------+------------------------------ Changes (by carter): * type: bug => feature request * milestone: => 7.10.1 Comment: So if you take a look at the haskell level primops that GHC provides http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.3.1.0 /GHC-Prim.html you'll notice that theres no primops for min or max on the underlying unlifted types Double# or Float# (or Int#). So if you need a branchless inner loop today, you'll either need to write a teeny bit of C you'll call out to, encode the logic as some bit fiddling on the floats, OR do something like describe the algorithm programmatically in a Haskell DSL, and at runtime use LLVM-General to generate the code you want http://hackage.haskell.org/package/llvm- general (i'm told some video codecs actually use LLVM for runtime code gen!) Adding these to ghc is a pretty reasonable feature request, though such wouldn't land till 7.10. If you're interested in doing some of the leg work , i'm happy to try to guide you through the process! (If not, thats fine too, its a really concrete task i'll give to someone who wants to do their first ghc patch, ) zooming out, 1. do you have any benchmarks (say, using criterion) for this code? 2. how does eg using -fllvm as your backend fair vs -fasm for this code in such a benchmark -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9246#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler