Forgot to also send to the list

Begin forwarded message:

From: Christiaan Baaij 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

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 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 | ghc-devs@haskell.org | 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