#13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description:

This came up during the GHC call while discussing #13397 and I thought it would be good to record.

Often in the compiler we end up with a case analysis with a number of alternatives and a `DEFAULT` case in place of the remaining alternative, {{{!#hs case x of True -> a DEFAULT -> b }}} Arguably we should instead generate, {{{ case x of True -> a False -> b }}} instead as this may allow the code generator may be able to emit better code when it knows the finite bounds of the switch (e.g. using a jump table).

New description: This came up during the GHC call while discussing #13397 and I thought it would be good to record. Often in the compiler we end up with a case analysis with a number of alternatives and a `DEFAULT` case in place of the remaining alternative, {{{#!hs case x of True -> a DEFAULT -> b }}} Arguably we should instead generate, {{{#!hs case x of True -> a False -> b }}} instead as this may allow the code generator may be able to emit better code when it knows the finite bounds of the switch (e.g. using a jump table). -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13523#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: 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 simonpj): If there is only one remaining constructor, GHC already replaces DEFAULT by that constructor. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13523#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: invalid => Comment: This was not about algebraic cases but primitive cases, for example on `Int#`. As far as I know the only situation where this will arise is when transforming {{{#!hs case tagToEnum# (x ==# y) of { False -> ... True -> ... } }}} to {{{#!hs case x ==# y of { 0# -> ... 1# -> ... } }}} By using `0#` and `1#` rather than `1#` (or `0#`) and `__DEFAULT` we could convey to the backend the information that the scrutinee is guaranteed to evaluate to either 0 or 1. With just two cases this probably doesn't matter, but when there are many cases we'd like to generate a jump table and if we know the scrutinee is guaranteed to be in-range then we can skip range checks. For an example usage, see `toChunk3#` in the attachment to #9159. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13523#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler