search for: laftertable

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

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

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

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