Forgot to also send to the list > Begin forwarded message: > > From: Christiaan Baaij <[email protected]> > Subject: Re: Strictness/demand analysis without worker/wrapper, or, reviving > -fmax-worker-args > Date: 15 Oct 2015 17:27:21 CEST > To: Simon Peyton Jones <[email protected]> > > Thanks for the comments, I will create a patch for a -fno-worker-wrapper flag > somewhere next week then. > > I’ll also see about reviving -fmax-worker-args. > Although it’s not used by any package on Hackage, and it has been dead for > over 2 years now I think. > > — Christiaan > >> On 14 Oct 2015, at 14:02, Simon Peyton Jones <[email protected]> wrote: >> >> Some quick thoughts: >> >> * It would make perfect sense to run the demand analyser without the >> worker/wrapper transform, yes. By all means make a patch to make that easy >> to do. Do NOT do this by setting -fmax-worker-args=0; that would be a hack >> even if it worked; and as you say it probably doesn't. >> >> * The -fmax-worker-args flag is supposed to stop GHC unpacking a function >> with a zillion fields. E.g. suppose we have >> f :: (Int,Int,Int, ..., Int, Int) -> Int >> which, say, adds up all the field of a 200-tuple. It would probably gain >> little to worker/wrapper this, because the worker would get 200 arguments. >> Maybe that's ok, but the gain over allocating the arg tuple in the heap is >> proportionately less. >> >> But clearly some refactoring lost this ability. Maybe someone should put it >> back! >> >> I have no evidence, either way, to suggest that limiting the # of args to a >> worker would be beneficial. Just a kind of intuition. >> >> >> Simon >> >> >> | As a GHC API user, I would like to run GHC’s strictness and demand >> analysis >> | pass, but I don’t want any worker/wrappers. >> | My specific use-case is to generate digital circuits from Haskell code, >> | where I’ve yet to encounter any benefit from worker/wrappers: the >> generated >> | circuits do not get any smaller or faster. >> | They do however induce longer compilation times for my compiler. >> | I still want to have GHC’s strictness and demand analysis, because, if I >> | understand correctly, the demand and strictness annotations are needed by >> | GHC’s dead code analysis (and other optimisations) which is beneficial for >> | my use case. >> | >> | Looking through DynFlags, I encountered the ‘maxWorkerArgs’ field, which >> is >> | controlled by ‘-fmax-worker-args’. >> | The user guide says the following: >> | "If a worker has that many arguments, none will be unpacked anymore >> | (default: 10)” >> | I don’t know exactly what this means, but I was hoping that if I would set >> | that number to 0 (zero), no worker/wrapper pairs would be created. >> | Is that correct? >> | >> | The reason that I’m asking is because -fmax-worker-args is basically dead >> | code. >> | The ‘maxWorkerArgs’ field of DynFlags is not used anywhere. >> | If setting ‘-fmax-worker-args’ to zero does indeed prevent any >> | worker/wrappers from being generated, should I reimplement the flag and >> | submit it as a patch? >> | Or, is it preferable to simply remove ‘-fmax-worker-args’ (given that it >> | doesn’t do anything right now), and create a new flag, ‘-fno-worker- >> | wrapper’, that simply disables the creation of worker/wrapper pairs >> | everywhere? >> | >> | Regards, >> | >> | Christiaan >> | _______________________________________________ >> | ghc-devs mailing list >> | [email protected] >> | >> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell >> | .org%2fcgi-bin%2fmailman%2flistinfo%2fghc- >> | >> devs%0a&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c6c87f8a67afa4d8c78 >> | >> 8108d2d3238a16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vk8RNAbzZpj63RRu >> | SQV%2fPDS7trt6puHaEhXBSHbIZQ0%3d >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
