search for: lc1df

...enabled we generate code for closures of this form: > > .text > .align 8 > .long Main_main1_srt-(Main_main1_info)+0 > .long 0 > .quad 4294967299 > .quad 0 > .quad 270582939663 > .globl Main_main1_info > .type Main_main1_info, @object > Main_main1_info: > .Lc1Df: > leaq -8(%rbp),%rax > cmpq %r15,%rax > jb .Lc1Dh Ok. I'd strongly recommend the approach of generating the table inside the prolog of the function. This means you'd get something like this: .text .align 8 .globl Main_main1_info .type Main_main1_info, @object Main_main1_in...

...orm: >> >> .text >> .align 8 >> .long Main_main1_srt-(Main_main1_info)+0 >> .long 0 >> .quad 4294967299 >> .quad 0 >> .quad 270582939663 >> .globl Main_main1_info >> .type Main_main1_info, @object >> Main_main1_info: >> .Lc1Df: >> leaq -8(%rbp),%rax >> cmpq %r15,%rax >> jb .Lc1Dh > > Ok. I'd strongly recommend the approach of generating the table inside the prolog of the function. This means you'd get something like this: > This is starting to look very similar to how ARM consta...

...iki/Commentary/Rts/Storage/HeapObjects#InfoTables With TNTC enabled we generate code for closures of this form: .text .align 8 .long Main_main1_srt-(Main_main1_info)+0 .long 0 .quad 4294967299 .quad 0 .quad 270582939663 .globl Main_main1_info .type Main_main1_info, @object Main_main1_info: .Lc1Df: leaq -8(%rbp),%rax cmpq %r15,%rax jb .Lc1Dh [...] .data .globl Main_main1_closure .type Main_main1_closure, @object Main_main1_closure: .quad Main_main1_info .quad 0 Without TNTC we instead generated code of this form: .text .globl Main_main1_entry .type Main_main1_entry, @function Mai...

...> .align 8 >> .long Main_main1_srt-(Main_main1_info)+0 >> .long 0 >> .quad 4294967299 >> .quad 0 >> .quad 270582939663 >> .globl Main_main1_info >> .type Main_main1_info, @object >> Main_main1_info: >> .Lc1Df: >> leaq -8(%rbp),%rax >> cmpq %r15,%rax >> jb .Lc1Dh > > Ok. I'd strongly recommend the approach of generating the table inside the prolog of the function. This means you'd get something like this: > This is starting to look very similar to how...

On Feb 13, 2012, at 6:49 AM, Sergiu Ivanov wrote: > On behalf of GHC hackers, I would like to discuss the possibility of > having a proper implementation of the tables-next-to-code optimisation > in LLVM. It would be great to have this. However, the design will be tricky. Is there anything that spells out how the TNTC optimization works at the actual machine instruction level? It

Hello everyone, On behalf of GHC hackers, I would like to discuss the possibility of having a proper implementation of the tables-next-to-code optimisation in LLVM. Currently, the object code produced by all three GHC backends follows the convention that the table with the metadata of a closure is located immediately before the code of the closure. This makes it possible to get to both the code