Questions concerning the LLVM backend - i.e. 'proc point splitting'

[Simon Peyton Jones]

David

All this stuff is terribly paged-out for me.  But I'd love someone to pay attention to some of this back-end stuff, so if you'd like to work there, I'd like to help you.

David Terei was also thinking of getting rid of proc point splitting for LLVM (see attached email and the notes attached to it)

Simon Marlow also was thinking about this; see his attached email.

The main *reason* for establishing a proc-point is so that, when generating C code (which we don't do any more) you can take its address.  E.g.

foo() {
  ...
  Push &bar onto the stack (effectively a return address)
  Jump to thingumpy
}

bar() {
  ...
}

Really bar is part of foo, but we have make it a separate top level thing so that we can take the address of bar and push it on the stack.

The trouble is that if there is a label inside bar that foo wants to jump to (i.e. without pushing &bar etc) then we have to make that label too into a proc-point, so that both foo and bar can see it.  Urgh.

In LLVM this probably is not true; presumably you can take the address of any label?

Avoiding proc-point splitting would be GREAT.

Simon


|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  David Spitzenberg
|  Sent: 12 November 2015 16:25
|  To: ghc-devs at haskell.org
|  Subject: Questions concerning the LLVM backend - i.e. 'proc point
|  splitting'
|  
|  Hello everybody,
|  
|  I've got some questions concerning the LLVM backend - i.e. the pass
|  'proc point splitting' in the cmm-pipeline.
|  
|  I'm new to this list as well as to computer science in general - at
|  least in some sense. Being a third semester student of computer
|  science, I'm not quite sure, whether I'm addressing the right list
|  with this mail. Feel free to correct me, if not.
|  
|  I'm doing numerical stencil calculations which heavily depend on
|  nested loops expressed as tail-recursive functions nested one in
|  another. When compiling a module, GHC seems capable of emitting pretty
|  good cmm-code.
|  At least as long as the loop bodies do not contain any call to non-
|  inlineable functions. In most cases 'loopification' fires and
|  transforms tail-recursive calls into loops.
|  
|  When calling into non-inlineable functions, 'proc point splitting' is
|  performed. This splits the loops into several mutually-recursive
|  functions therefore significantly decreasing the possibilities of
|  'opt'
|  in optimizing the code later on. This leads to pretty bad performance
|  of the whole calculation.
|  
|  To avoid the presence of proc points within a loop body - and by doing
|  so the splitting of the body - I currently try to avoid calls into
|  non-inlineable functions by merging the nested recursive functions
|  into one giant tail-recursive function. This works, as long as
|  everything not defined in the module being compiled can be inlined.
|  Apparently, this is not a long term solution.
|  
|  
|  
|  My questions:
|  
|   - The reason to perform 'proc point splitting' is, that LLVM IR lacks
|  of the possibility to call into an arbitrary basic block of a function
|  body from outside the function itself. Is this understanding right?
|  
|   - Are there any other possibilities to avoid 'proc point splitting'
|  when using LLVM as a backend?
|  
|   - I recently read the article on an improved LLVM backend in the GHC
|  wiki (https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend), but
|  couldn't find any suggestions on the topic of 'proc point splitting'.
|  Are there any plans to solve the problem either by teaching LLVM IR
|  the lacking functionality or in any other way?
|  
|  
|  
|  I'd really like to contribute to GHC by working on this problem, but
|  I'm not quite sure, if I'm capable of doing so. My background
|  knowledge is still somewhat limited, but I'm working on it ;-)
|  
|  Thanks in advance for your help!
|  
|  Regards,
|  
|  David Spitzenberg
|  
|  PS.: Thanks to everyone for the great work you're doing on GHC!
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h
|  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cfe71402ab68e40b
|  9777408d2eb7ddf90%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bqkhoth
|  1Ui6FRUwEbfHajdjx7g9bSrM25geCCDREdus%3d
-------------- next part --------------
An embedded message was scrubbed...
From: David Terei <davidterei at gmail.com>
Subject: Re: Hoopl profiling
Date: Fri, 18 Mar 2011 23:20:03 +0000
Size: 24312
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151120/eef4a8bc/attachment-0002.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: Simon Marlow <simonmar at microsoft.com>
Subject: RE: LLVM optimisation passes / tables next to code
Date: Mon, 19 Mar 2012 10:12:35 +0000
Size: 8825
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151120/eef4a8bc/attachment-0003.mht>