[LLVMdev] LLVM IR is a compiler IR

[Justin Holewinski]

On Wed, Oct 5, 2011 at 11:58 AM, Renato Golin <rengolin at systemcall.org>wrote:

> On 5 October 2011 16:18, Dan Gohman <gohman at apple.com> wrote:
> > I think you're overreacting here.  There is nothing about OpenCL,
> RenderScript,
> > or VMKit that requires LLVM IR be used like a Platform, as I defined it
> in my
> > first paragraph.  I'm aware that some people would like to use LLVM IR as
> a
> > Platform, and I'm saying that there are important high-level
> considerations
> > to make before doing so, and my impression is that there is little
> discussion of
> > issues I consider important.
>
> Hi Dan,
>
> I probably am. And that got in the way of highlighting the real issue.
>
> As Kenneth just highlighted, there is a gap, and people are trying to
> fill that gap. I personally prefer to use LLVM for that job, instead
> of Java bytecode, and it seems many people feel the same.
>
> So, let's separate the issues here:
>
>  1) LLVM IR is a compiler IR, nothing else, nor should be. I agree
> with David, this is not a bad thing. Case closed.
>
>  2) Has LLVM the potential to fill that gap via other routes?
>
> Can LLVM do (one day) what you wanted it to do today? A higher level
> representation for light-weight JITs, a rich type-system for complex
> linkage of higher languages, special semantics for special purposes,
> etc.
>
> Today, LLVM IR is NOT portable, so why worry about the portability of
> DSLs around it? OpenCL rep. can be different (in syntax, and
> semantics) from C++ rep., but it should be similar to RenderScript
> rep. If you want to link CL and C++ reps, lower them to LLVM IR, or
> use the common subset.
>

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.

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.


>
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111005/4311e7d8/attachment.html>