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/
On Wed, Oct 5, 2011 at 4:47 PM, Renato Golin <rengolin at systemcall.org>wrote:> 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. >Right, sorry, I meant LLVM IR. I'm not clear to me that there is any significant advantage to making LLVM *IR* platform/architecture-agnostic. The benefits may not outweigh the disadvantages.> > 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. >Yes, I agree 100%. I would much rather see LLVM IR stay platform-dependent, and let different higher-level representations be used for platform-agnostic work.> > 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/ >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111005/753eebf6/attachment.html>
Now that the dust begins to settle... I'm wondering whether LLVM is for me. I'm working on something that can be used to create software for different environments: C/C++, JVM, CLR, Parrot, etc. I.e. one language for different environments, but not write once, run anywhere. Now what would be the role of LLVM in such an infrastructure? Just backend for C/C++ linkage, and I should go and look elsewhere for JVM/CLR/whateverVM? Should I look into LLVM subprojects? Which ones? Regards, Jo
Joachim Durchholz <jo at durchholz.org> writes:> Now that the dust begins to settle... I'm wondering whether LLVM is for me. > > I'm working on something that can be used to create software for > different environments: C/C++, JVM, CLR, Parrot, etc. > I.e. one language for different environments, but not write once, run > anywhere. > > Now what would be the role of LLVM in such an infrastructure? > Just backend for C/C++ linkage, and I should go and look elsewhere for > JVM/CLR/whateverVM? > Should I look into LLVM subprojects? Which ones?It depends on what you want to do with the IR. If you want to create object files, LLVM is great. You just need to map the semantics of the various HLLs onto the LLVM IR language, as with any translator. For any kind of code-generator-ish thing, it's hard to beat LLVM IR, IMHO. If you want to JIT, then some of LLVM IR's limitations will impact the speed of code generation, as Dan outlined. If you want to do fancy transformations that use or analyze high-level language semantics, LLVM IR may not be right for you, as most of that information is lost by the time the code has been converted to LLVM IR. -Dave