[LLVMdev] LLVM IR is a compiler IR
justin.holewinski at gmail.com
Wed Oct 5 10:03:56 PDT 2011
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,
> > 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
> > Platform, and I'm saying that there are important high-level
> > 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,
> 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
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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev