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

[Ben Gamari]

David Spitzenberg <spitzenb at fim.uni-passau.de> writes:

> Hello Simon, hello Ben,
>
> thank you very much to both of you for your encouraging answers!
>
Hello again!

> First of all, I've two questions concerning your answer, Ben.
>
> a)
>
>> The jump issue aside, I don't know how you would deal with
>> tables-next-to-code. The prefix data support that currently available
>> in LLVM is attached to functions and I unfortunately don't see that
>> changing any time soon.
>
> Looks like I messed things up with those info-tables. As far as I
> understood [1], these are part of the STG. Therefore, every function
> present at the STG-level needs a info-table. The code generator does
> generate info-tables for every proc-point after splitting them. But to
> me, this was a consequence of making them stand-alone functions.
>
> Could you explain the need of further info-tables for 'inner'
> proc-points (those, which are not the entry-block of a function) to me,
> please?

Ahh, yes. I believe you are right; there should be no need for info
tables on these proc-points given that they don't correspond to anything
in the STG program. My apologies for muddying things!

snip
>
> To make control flow more apparent to LLVM, they came up with the
> following idea. Remark before showing the idea: I know that it greatly
> interferes with CPS. It leaves parts of the continuation-handling to the
> implicit LLVM call-stack. Further, this does not solve the problem of
> proc-point splitting at all. It is more a workaround than a solution.
> But it would greatly increase LLVM's possibilities to optimize code
> later on. That's why I found this idea worth mentioning. Especially
> because after reading your answer, Ben, I'm somewhat convinced that
> solving the problem of proc-point splitting is nearly impossible with
> the capabilities of LLVM IR available at the moment. Now back to the idea.
>
Well, don't let me dissuade you: firstly, I'm a rather fallible human
and may have missed something; secondly, the LLVM folks have been quite
receptive to new ideas and there is likely a reason they left the door
open to expressing inter-procedure block references with `blockaddress`.
You might consider asking about this on the LLVM list, assuming this
isn't beyond the scope of your project.

I'll leave the rest for those with better understanding of the whole
picture to address.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151127/65a16cfa/attachment.sig>