<div class="gmail_quote">On Wed, Oct 5, 2011 at 11:58 AM, Renato Golin <span dir="ltr"><<a href="mailto:rengolin@systemcall.org">rengolin@systemcall.org</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 5 October 2011 16:18, Dan Gohman <<a href="mailto:gohman@apple.com">gohman@apple.com</a>> wrote:<br>
> I think you're overreacting here.  There is nothing about OpenCL, RenderScript,<br>
> or VMKit that requires LLVM IR be used like a Platform, as I defined it in my<br>
> first paragraph.  I'm aware that some people would like to use LLVM IR as a<br>
> Platform, and I'm saying that there are important high-level considerations<br>
> to make before doing so, and my impression is that there is little discussion of<br>
> issues I consider important.<br>
<br>
</div>Hi Dan,<br>
<br>
I probably am. And that got in the way of highlighting the real issue.<br>
<br>
As Kenneth just highlighted, there is a gap, and people are trying to<br>
fill that gap. I personally prefer to use LLVM for that job, instead<br>
of Java bytecode, and it seems many people feel the same.<br>
<br>
So, let's separate the issues here:<br>
<br>
 1) LLVM IR is a compiler IR, nothing else, nor should be. I agree<br>
with David, this is not a bad thing. Case closed.<br>
<br>
 2) Has LLVM the potential to fill that gap via other routes?<br>
<br>
Can LLVM do (one day) what you wanted it to do today? A higher level<br>
representation for light-weight JITs, a rich type-system for complex<br>
linkage of higher languages, special semantics for special purposes,<br>
etc.<br>
<br>
Today, LLVM IR is NOT portable, so why worry about the portability of<br>
DSLs around it? OpenCL rep. can be different (in syntax, and<br>
semantics) from C++ rep., but it should be similar to RenderScript<br>
rep. If you want to link CL and C++ reps, lower them to LLVM IR, or<br>
use the common subset.<br></blockquote><div><br></div><div>It seems to me like that real issue is: should LLVM IR be platform/architecture-agnostic? It seems pretty clear that it currently is not, and as others have pointed out, I do not see this being a particular problem.</div>
<div><br></div><div>I see people comparing LLVM IR to Java/CLR bytecode, but I'm not sure that is the right comparison to be making.  The way I see LLVM, it's the lower-level, platform-specific equivalent of platform-independent Java/CLR bytecode.  Some optimizations/transformations/analyses are better performed on high-level representations, and some on the low-level representations.  So why must LLVM try to meet *both* goals?  Instead, different types of front-ends can use custom intermediate representations that meet their needs, and then lower to platform-specific LLVM IR before final code emission.  I'm afraid that if LLVM gets into the game of trying to be the intermediate representation for *everything*, then it will suffer.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
--<br>
cheers,<br>
--renato<br>
<br>
<a href="http://systemcall.org/" target="_blank">http://systemcall.org/</a><br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>