Fwd: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args
christiaan.baaij at gmail.com
Thu Oct 15 16:03:07 UTC 2015
Forgot to also send to the list
> Begin forwarded message:
> From: Christiaan Baaij <christiaan.baaij at gmail.com>
> 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 <simonpj at microsoft.com>
> 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 <simonpj at microsoft.com> 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.
>> | 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs