From b2be257b55530f9e7d85362aee2ce86b935aeac2 Mon Sep 17 00:00:00 2001 From: "simonpj@microsoft.com" Date: Fri, 14 Jan 2011 16:29:59 +0000 Subject: [PATCH] Comments only --- compiler/stranal/WorkWrap.lhs | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/compiler/stranal/WorkWrap.lhs b/compiler/stranal/WorkWrap.lhs index 8ddea65..d566d98 100644 --- a/compiler/stranal/WorkWrap.lhs +++ b/compiler/stranal/WorkWrap.lhs @@ -182,10 +182,22 @@ has happened. So we take the precaution of adding an INLINE pragma to any such functions. I made this change when I observed a big function at the end of -compilation with a useful strictness signature but no w-w. When -I measured it on nofib, it didn't make much difference; just a few -percent improved allocation on one benchmark (bspt/Euclid.space). -But nothing got worse. +compilation with a useful strictness signature but no w-w. (It was +small during demand analysis, we refrained from w/w, and then got big +when something was inlined in its rhs.) When I measured it on nofib, +it didn't make much difference; just a few percent improved allocation +on one benchmark (bspt/Euclid.space). But nothing got worse. + +There is an infelicity though. We may get something like + f = g val +==> + g x = case gw x of r -> I# r + + f {- InlineStable, Template = g val -} + f = case gw x of r -> I# r + +The code for f duplicates that for g, without any real benefit. It +won't really be executed, because calls to f will go via the inlining. Note [Wrapper activation] ~~~~~~~~~~~~~~~~~~~~~~~~~ -- 1.7.10.4