Questions on 'proc point splitting' again

[Simon Peyton Jones]

Maybe you could just maintain a separate map "on the side" and push it through to the LLVM code gen?

I hate the whole proc-point machinery.  It's all caused by our inability to take the address of a local label.  So to push a return address on the stack we have to make it a top-level "procedure" and that gives rise to all the proc-point pain.  For the native code generator none of this is necessary (I think).

It's also annoyingly invasive.  Somehow proc-points ought to be localised to the LLVM back end, not pervasive in the Cmm pipeline.

In short, if you get deep into this, do feel free to propose something better!

Simon

|  -----Original Message-----
|  From: David Spitzenberg [mailto:spitzenb at fim.uni-passau.de]
|  Sent: 04 March 2016 08:40
|  To: Ben Gamari <ben at well-typed.com>; Simon Peyton Jones
|  <simonpj at microsoft.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: Questions on 'proc point splitting' again
|  
|  
|  
|  On 03/03/2016 11:32 AM, Ben Gamari wrote:
|  
|  >> Given a CmmGraph, is there a possibility to annotate information to
|  a
|  >> single node within this graph? I.e. I want to annotate to certain
|  >> CmmCalls that they where introduced by 'proc point splitting'. I
|  >> would like to slightly modifiy the generation of LLVM IR for such
|  Calls later on.
|  >>
|  > My guess here would be to map the CmmGraph (which is simply a type
|  > synonym for `GenCmmGraph CmmNode` to something of type `GenCmmGraph
|  > AnnCmmNode` where AnnCmmNode carries a CmmNode along with whatever
|  > other information you'd like to preserve.
|  >
|  > This then poses the question of what you'd like to *do* with this
|  > graph, since you'll be unable to use much of the GHC's existing
|  machinery.
|  > My (possibly mistaken) impression is that we don't have a terribly
|  > great story in GHC for working with arbitrarily annotated Cmm graphs.
|  
|  Thank you very much, Ben. Basically, I just want the annotation to be
|  propagated all the way down to the backend-code generation (llvmGen in
|  this case). At the moment, I can't find any need to modify the map you
|  suggest in between. So using the existing machinery shouldn't be
|  necessary to do any work on the map itself. Propagating this newly
|  introduced map to where I want to use it seems harder, though.
|  
|  I'm going to have a look at it and put some more questions to you, if I
|  struggle to find a way to propagate the map.
|  
|  Regards,
|  
|  David