llvm dev - Oct 2011 - [LLVMdev] LLVM IR is a compiler IR

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.


-- 
cheers,
--renato

http://systemcall.org/

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>

On 5 October 2011 18:03, Justin Holewinski <justin.holewinski at
gmail.com> wrote:
>  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.
Hi Justin,

You seem to be intermixing LLVM vs. LLVM IR.

I think LLVM can have as many sub-projects as people want to, and they
can create as many new shiny things as they want. LLVM IR, on the
other hand, has specific goals and should keep tight to it.

As I said before, IR is what it is. But LLVM is not *just* the IR...
There is a lot more that can be done, and Polly and OpenCL are just
the beginning...



-- 
cheers,
--renato

http://systemcall.org/