So a chain of equality comparisons will turn into a table-driven jump in
#9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:12 simonpj]: the end, which is a good thing. On the other hand, generating branch nests is a bad thing. You call this a "table-driven jump", and that may be the case for something like `0,1,2` (I don't know), but it certainly does ''not'' seem to work like that for, say, `32, 9, 10, 11, 12, 168`, or whatever the numbers are for "is a space".
So perhaps `litEq` should apply only ''when in the context of a `case` expression that immediately scrutinises its result''. So `litEq` would become {{{ case (a ==# k) of 1# -> e1; _ -> e2 ---> case a of { k -> e1; _ -> e2 } }}} Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give access to the context of an application (the `SimplCont`), but it would not be hard to make it do so.
So if that is the right rewrite, then it'd be another useful project for someone.
I don't have a clear sense of what you're getting at, but in the situations I'm thinking about (avoiding poorly predicted branches), the compiler may not be able to know what is best, and Reid Barton's "secret" equality predicate may be the best approach. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9661#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler