<div dir="ltr">May not be mandatory but it certainly just emits the values directly before the prologue... I&#39;m guessing this doesn&#39;t affect IR level optimizations but likely breaks machine code optimizations without a relative jump to the body in the prefix-data.<div>
<br></div><div><a href="https://gist.github.com/NathanHowell/6589820">https://gist.github.com/NathanHowell/6589820</a><br></div><div><br></div><div>-n</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 3:09 PM, Gabor Greif <span dir="ltr">&lt;<a href="mailto:ggreif@gmail.com" target="_blank">ggreif@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 9/16/13, Carter Schonwald &lt;<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>&gt; wrote:<br>

&gt; yup! its exciting.<br>
&gt;<br>
&gt; we were talking about this a bit earlier today on #haskell-llvm, and it<br>
&gt; sounds doable.<br>
&gt; There were some concerns that folks had, but hopefully we can give the llvm<br>
&gt; devs feedback about this before its finalized in LLVM 3.4 so it doesn&#39;t<br>
&gt; come with any performance caveats for ghc.<br>
<br>
</div>I almost sobered when I read that there must be a machine instruction<br>
embedded in the prefix, but looking at the testcases this doesn&#39;t<br>
appear like being mandatory. The prefix can be a simple struct, just<br>
like TNTC.<br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt; On Mon, Sep 16, 2013 at 5:14 PM, Gabor Greif &lt;<a href="mailto:ggreif@gmail.com">ggreif@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; This looks pretty exiting for LLVM IR-generation:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042.html</a><br>
&gt;&gt;<br>
&gt;&gt; GHC 7.10 might generate LLVM IR including embedded tables without<br>
&gt;&gt; resorting to linker tricks/postprocessing when targeting LLVM 3.4!<br>
&gt;&gt;<br>
&gt;&gt; The relevant LLVM bug is <a href="http://llvm.org/bugs/show_bug.cgi?id=14080" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=14080</a><br>
&gt;&gt;<br>
&gt;&gt; and GHC Trac: <a href="http://ghc.haskell.org/trac/ghc/ticket/4213" target="_blank">http://ghc.haskell.org/trac/ghc/ticket/4213</a><br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt;<br>
&gt;&gt;     Gabor<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; ghc-devs mailing list<br>
&gt;&gt; <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
&gt;&gt;<br>
&gt;<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>