Re: [FYI] LLVM: function prefix data (a.k.a. tables-next-to-code) committed

May not be mandatory but it certainly just emits the values directly before the prologue... I'm guessing this doesn't affect IR level optimizations but likely breaks machine code optimizations without a relative jump to the body in the prefix-data. https://gist.github.com/NathanHowell/6589820 -n On Mon, Sep 16, 2013 at 3:09 PM, Gabor Greif wrote:

On 9/16/13, Carter Schonwald wrote:

...

yup! its exciting.

we were talking about this a bit earlier today on #haskell-llvm, and it sounds doable. There were some concerns that folks had, but hopefully we can give the llvm devs feedback about this before its finalized in LLVM 3.4 so it doesn't come with any performance caveats for ghc.

I almost sobered when I read that there must be a machine instruction embedded in the prefix, but looking at the testcases this doesn't appear like being mandatory. The prefix can be a simple struct, just like TNTC.

...

On Mon, Sep 16, 2013 at 5:14 PM, Gabor Greif wrote:

...

This looks pretty exiting for LLVM IR-generation:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042....

...

...

GHC 7.10 might generate LLVM IR including embedded tables without resorting to linker tricks/postprocessing when targeting LLVM 3.4!

The relevant LLVM bug is http://llvm.org/bugs/show_bug.cgi?id=14080

and GHC Trac: http://ghc.haskell.org/trac/ghc/ticket/4213

Cheers,

Gabor _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs