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 <ggr...@gmail.com> wrote: > On 9/16/13, Carter Schonwald <carter.schonw...@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 > 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 <ggr...@gmail.com> wrote: > > > >> This looks pretty exiting for LLVM IR-generation: > >> > >> > >> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042.html > >> > >> 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
