<div dir="ltr"><br><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your reply.<br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 15, 2013 at 9:15 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></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 Mon, Apr 15, 2013 at 3:32 PM, Hongbo Zhang <<a href="mailto:bobzhang1988@gmail.com">bobzhang1988@gmail.com</a>> wrote:<br>

> Hi all,<br>
>    I am trying to compile my toy language to LLVM back end. (I am new to<br>
> LLVM, so my questions may sound naive)<br>
>    I am looking at some tutorials about LLVM, most are about how to use LLVM<br>
> IRBuilder, however, I find the API provided by IRBuilder is quite imperative<br>
> and verbose, and the API changes so fast that most of the tutorials are out<br>
> of dated.<br>
>    So I am wondering what's the benefit of emitting LLVM IR using IRBuilder<br>
> compared with designing my own abstract syntax in a high-level programming<br>
> language(e.g. Haskell or OCaml) and unparsing it to LLVM IR.<br>
<br>
</div>To be clear you're suggesting having your frontend (say, for<br>
argument's sake, written in C++) parse your toy language and then emit<br>
a (say) Haskell representation of IR? Using some Haskell APIs you'll<br>
write that will emit LLVM bitcode? And then running the resulting<br>
Haskell program to produce your bitcode that you'll load back in to<br>
LLVM to optimize/compile?<br>
<div class="im"><br></div></blockquote><div> Yes, that's what I am doing, in OCaml though. Functional languages are excellent <br></div><div>for program transformation and manipulation. Where is the specification for the bitcode format?<br>
</div><div>Thanks<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Is there some<br>
> benefit of using IRBuilder I ignored here?<br>
<br>
</div>It'll be more efficient to keep the IR in memory rather than to go out<br>
to a source file, run that file to produce bitcode, then load that<br>
bitcode in to LLVM.<br>
<br>
Also I'm not sure I see quite how that scheme would be less verbose.<br>
<div class="im"><br>
> And I have some follow-up<br>
> questions: 1. How stable is the IR format?<br>
<br>
</div>There's in-built autoupgrade so that you can load old IR in newer<br>
versions of LLVM (any 3.* series should be compatible, I believe).<br>
<div class="im"><br>
> 2. Is the binary representation<br>
> of IR format (*.bc) stable and the same across different platforms?<br>
<br>
</div>It's the same format, but the actual bitcode isn't retargetable, as<br>
such. (ie: don't expect to be able to produce bitcode that you can<br>
compile for different architectures)<br>
<div class="im"><br>
> 3. Is<br>
> there any previous work of building a declarative`interface instead of using<br>
> IRBuilder?<br>
<br>
</div>Not that I know of. The frontends tend to use IRBuilder.<br>
<br>
>    Thank you in advance!<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div>Regards</div>-- Bob
</div></div>