[FYI] LLVM: function prefix data (a.k.a. tables-next-to-code) committed
nathan.d.howell at gmail.com
Tue Sep 17 03:42:59 UTC 2013
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.
On Mon, Sep 16, 2013 at 3:09 PM, Gabor Greif <ggreif at gmail.com> wrote:
> On 9/16/13, Carter Schonwald <carter.schonwald at gmail.com> 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
> > 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 <ggreif at gmail.com> wrote:
> >> This looks pretty exiting for LLVM IR-generation:
> >> 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 at haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs