- -- We want to make wrapper-style evaluation look cheap, so that
- -- when we inline a wrapper it doesn't make call site (much) bigger
- -- Otherwise we get nasty phase ordering stuff:
- -- f x = g x x
- -- h y = ...(f e)...
- -- If we inline g's wrapper, f looks big, and doesn't get inlined
- -- into h; if we inline f first, while it looks small, then g's
- -- wrapper will get inlined later anyway. To avoid this nasty
- -- ordering difference, we make (case a of (x,y) -> ...) look free.
- size_up (Case (Var v) _ [alt])
- | v `elem` top_args
- = size_up_alt alt `addSize` SizeIs 0# (unitBag (v, 1)) 0#
+ size_up (Case (Var v) _ alts)
+ | v `elem` top_args -- We are scrutinising an argument variable
+ =
+{- I'm nuking this special case; BUT see the comment with case alternatives.
+
+ (a) It's too eager. We don't want to inline a wrapper into a
+ context with no benefit.
+ E.g. \ x. f (x+x) o point in inlining (+) here!
+
+ (b) It's ineffective. Once g's wrapper is inlined, its case-expressions
+ aren't scrutinising arguments any more
+
+ case alts of
+
+ [alt] -> size_up_alt alt `addSize` SizeIs 0# (unitBag (v, 1)) 0#
+ -- We want to make wrapper-style evaluation look cheap, so that
+ -- when we inline a wrapper it doesn't make call site (much) bigger
+ -- Otherwise we get nasty phase ordering stuff:
+ -- f x = g x x
+ -- h y = ...(f e)...
+ -- If we inline g's wrapper, f looks big, and doesn't get inlined
+ -- into h; if we inline f first, while it looks small, then g's
+ -- wrapper will get inlined later anyway. To avoid this nasty
+ -- ordering difference, we make (case a of (x,y) -> ...),
+ -- *where a is one of the arguments* look free.
+
+ other ->
+-}
+ alts_size (foldr addSize sizeOne alt_sizes) -- The 1 is for the scrutinee
+ (foldr1 maxSize alt_sizes)
+