From beade0a18125941847f87c97f81c1e0a49f01416 Mon Sep 17 00:00:00 2001 From: "simonpj@microsoft.com" Date: Wed, 29 Nov 2006 19:42:12 +0000 Subject: [PATCH] Comments only --- compiler/specialise/SpecConstr.lhs | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-) diff --git a/compiler/specialise/SpecConstr.lhs b/compiler/specialise/SpecConstr.lhs index 10010cc..5cccf80 100644 --- a/compiler/specialise/SpecConstr.lhs +++ b/compiler/specialise/SpecConstr.lhs @@ -115,7 +115,7 @@ This happens if Hence the "OR" part of Note [Good arguments] below. -ALTERNATIVE: pass both boxed and unboxed versions. This no longer saves +ALTERNATIVE 2: pass both boxed and unboxed versions. This no longer saves allocation, but does perhaps save evals. In the RULE we'd have something like @@ -125,6 +125,25 @@ If at the call site the (I# x) was an unfolding, then we'd have to rely on CSE to eliminate the duplicate allocation.... This alternative doesn't look attractive enough to pursue. +ALTERNATIVE 3: ignore the reboxing problem. The trouble is that +the conservative reboxing story prevents many useful functions from being +specialised. Example: + foo :: Maybe Int -> Int -> Int + foo (Just m) 0 = 0 + foo x@(Just m) n = foo x (n-m) +Here the use of 'x' will clearly not require boxing in the specialised function. + +The strictness analyser has the same problem, in fact. Example: + f p@(a,b) = ... +If we pass just 'a' and 'b' to the worker, it might need to rebox the +pair to create (a,b). A more sophisticated analysis might figure out +precisely the cases in which this could happen, but the strictness +analyser does no such analysis; it just passes 'a' and 'b', and hopes +for the best. + +So my current choice is to make SpecConstr similarly aggressive, and +ignore the bad potential of reboxing. + Note [Good arguments] ~~~~~~~~~~~~~~~~~~~~~ @@ -593,10 +612,10 @@ instance Outputable ArgOcc where ppr BothOcc = ptext SLIT("both-occ") ppr NoOcc = ptext SLIT("no-occ") --- Experimentally, this vresion of combineOcc makes ScrutOcc "win", so +-- Experimentally, this vesion of combineOcc makes ScrutOcc "win", so -- that if the thing is scrutinised anywhere then we get to see that -- in the overall result, even if it's also used in a boxed way --- This might be too agressive; see Note [Reboxing] +-- This might be too agressive; see Note [Reboxing] Alternative 3 combineOcc NoOcc occ = occ combineOcc occ NoOcc = occ combineOcc (ScrutOcc xs) (ScrutOcc ys) = ScrutOcc (plusUFM_C combineOccs xs ys) -- 1.7.10.4