Displaying 4 results from an estimated 4 matches for "laftert".
Did you mean:
lautert
2012 Feb 14
0
[LLVMdev] LLVM GHC Backend: Tables Next To Code
...like to see the codegen that you guys are after to try to help come up with another suggestion that isn't a complete one-off hack for GHC. :)
One random question: have you considered placing the table *inside* of the function? If the prologue for the closure was effectively:
Closure:
jmp .LAfterTable
.word ...
.word ...
.LAfterTable:
push $rbp
...
then you can avoid a lot of problems. I realize that this is not going to be absolutely as fast as your current TNTC implementation, but processors are *really really* good at predicting unconditional branches, so the cost is probably m...
2012 Feb 13
3
[LLVMdev] LLVM GHC Backend: Tables Next To Code
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
2012 Mar 13
3
[LLVMdev] LLVM GHC Backend: Tables Next To Code
...en that you guys are after to try to help come up with another suggestion that isn't a complete one-off hack for GHC. :)
>
> One random question: have you considered placing the table *inside* of the function? If the prologue for the closure was effectively:
>
> Closure:
> jmp .LAfterTable
> .word ...
> .word ...
> .LAfterTable:
> push $rbp
> ...
>
> then you can avoid a lot of problems. I realize that this is not going to be absolutely as fast as your current TNTC implementation, but processors are *really really* good at predicting unconditional branch...
2012 Feb 14
3
[LLVMdev] LLVM GHC Backend: Tables Next To Code
...en that you guys are after to try to help come up with another suggestion that isn't a complete one-off hack for GHC. :)
>
> One random question: have you considered placing the table *inside* of the function? If the prologue for the closure was effectively:
>
> Closure:
> jmp .LAfterTable
> .word ...
> .word ...
> .LAfterTable:
> push $rbp
> ...
>
> then you can avoid a lot of problems. I realize that this is not going to be absolutely as fast as your current TNTC implementation, but processors are *really really* good at predicting unconditional branch...