On 15 March 2012 01:58, Chris Lattner 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 exten
Chris said:
> 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 an
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? How do you envision this would look at the
IR level, how much
> > The table size is variable - between 2 and 6 32- or 64-bit words, where
> 2-3 is the common case. This means Chris's trick of adjusting the pointer
> by a fixed amount to point directly to the code doesn't work unless we pad
> the table to the worst-case size all the time, which wastes a lot
> > Since the jmp is a fixed 2 bytes (0xEB, tablesize), all references to
> the table can still be done with trivial pc/RIP-relative addressing within
> the closure, and you just need one pointer for both the table and the
> closure data.
> Only if tablesize fits in 127 bytes. Otherwise it will us
Hmm writing a blog post about TNTC is beyond the time I have right now.
Here is some high level documentation of the layout of Heap objects in GHC:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables
With TNTC enabled we generate code for closures of this form:
