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 <ggreif@gmail.com> wrote:
On 9/16/13, Carter Schonwald <carter.schonwald@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 <ggreif@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