Fwd: Strictness/demand analysis without worker/wrapper, or, reviving -fmax-worker-args

[Christiaan Baaij]

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.
>> 
>> 
>> 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 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...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151015/00c3e708/attachment.html>