[LLVMdev] LLVM GHC Backend: Tables Next To Code

[David Terei]

On 15 March 2012 01:58, Chris Lattner <clattner at apple.com> wrote:
>
> On Mar 13, 2012, at 4:36 PM, David Terei wrote:
>
>> Hi Chris,
>>
>> One remaining question here is, if the GHC team tries some of these
>> alternative schemes and finds them unsatisfactory what is the LLVM
>> communities feeling in regards to extending LLVM IR to support
>> directly implementing TNTC?
>
> I'm strongly in favor of getting proper support for TNTC, because your workarounds (while very pragmatic!) give me the shivers :).  I'd much rather have a proper solution that works well with the rest of the llvm toolchain.
>
> That said, the design and implementation needs to fit in well with the rest of llvm.  I'm not willing to add a crazy completely-special purpose bolt-on extension just to support this, which means that we need to find a way to design it that makes sense in the larger context of llvm.

OK great! I have no idea when we on the GHC side (me) will get time to
tackle this so don't hold your breath. Good to know where you guys
stand though. We began this conversation as a GSoC student is
interested in tackling it so we may progress down that path.

>
>> How do you envision this would look at the
>> IR level, how much work do you think it would be and most importantly
>> do you feel LLVM would be willing to accept patches for it?
>
> I really like the idea of adding this as an inline asm blob at the start of a function, and biasing the actual address of the closure based on the size of the table.  I'm not 100% confident that it will work (not being very familiar with TNTC) but it seems quite plausible and the impact on LLVM would be quite reasonable (some new calling convention work?)
>
> -Chris

I personally would prefer something like Gabor suggests that is
platform agnostic but am not fussed on the issue, whatever works (and
isn't a hack) is my goal.

Cheers,
David