search for: laftert

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...