Thanks Dan for your responses !<div><div><br></div><div><br><div><br></div><div><br><div class="gmail_quote">On Thu, Jul 19, 2012 at 2:54 AM, Dan Gohman <span dir="ltr"><<a href="mailto:gohman@apple.com" target="_blank">gohman@apple.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 Jul 18, 2012, at 2:39 PM, Pierre P <<a href="mailto:ploploplop123@gmail.com">ploploplop123@gmail.com</a>> wrote:<br>

<br>
> Hi llvm list !<br>
><br>
> Everything is in the question.<br>
> I've read this discussion on the mailinglist  [LLVMdev] LLVM IR is a compiler IR.<br>
> But since llvm3 and type system rewrite, is it a good idea to rethink about a VM wich could run the IR bytecode directly?<br>
<br>
</div>The type system changes you mention changed the way struct types<br>
are named and uniqued, but structs are still just structs. This<br>
change doesn't really make LLVM IR higher-level in any way that<br>
would significantly affect the issues discussed in that thread.<br>
<div class="im"><br>
><br>
> llvm has differents bytecode from low level, to more hight level... So do you see some interest to have this kind of VM for one of this bytcode ?<br>
> Is it hight level enougth like java byte code ?<br>
<br>
</div>Java bytecode remains much much higher-level than LLVM IR; this<br>
hasn't significantly changed.<br>
<div class="im"><br>
><br>
> My second obvious question is about the bycode format, is it stable enought to concider using it as an 'archive' source/byte code ?<br>
<br>
</div>Quite a few people are interested in keeping the bitcode format<br>
stable these days, so it will probably remain fairly stable for the<br>
foreseeable future.<br>
<br>
That said, as far as I'm aware all of the issues discussed in the<br>
"LLVM IR is a compiler IR" thread are at least as relevant today as<br>
they were then.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
<br>
</font></span></blockquote></div><br></div></div></div>