similar to: [LLVMdev] LLVM IR is a compiler IR

Thank you for writing this. First, I'd like to say that I am in 100% agreement with your points. I've been tempted many times to write something similar, although what you've written has been articulated much better than what I would have said. When I try to explain to people what LLVM is I say "It's essentially the back-end of a compiler" - a job it does extremely well.

On Oct 4, 2011, at 11:53 AM, Dan Gohman wrote: > In this email, I argue that LLVM IR is a poor system for building a > Platform, by which I mean any system where LLVM IR would be a > format in which programs are stored or transmitted for subsequent > use on multiple underlying architectures. Hi Dan, I agree with almost all of the points you make, but not your conclusion. Many of the

On Tue, Oct 4, 2011 at 4:19 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 4, 2011, at 11:53 AM, Dan Gohman wrote: > > In this email, I argue that LLVM IR is a poor system for building a > > Platform, by which I mean any system where LLVM IR would be a > > format in which programs are stored or transmitted for subsequent > > use on multiple underlying

On Oct 4, 2011, at 4:56 PM, Talin wrote: > > LLVM isn't actually a virtual machine. It's widely acknoledged that the > > name "LLVM" is a historical artifact which doesn't reliably connote what > > LLVM actually grew to be. LLVM IR is a compiler IR. > > It sounds like you're picking a very specific definition of what a VM is. LLVM certainly

On Tue, Oct 4, 2011 at 5:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 4, 2011, at 4:56 PM, Talin wrote: > > > LLVM isn't actually a virtual machine. It's widely acknoledged that the >> > name "LLVM" is a historical artifact which doesn't reliably connote what >> > LLVM actually grew to be. LLVM IR is a compiler IR.

On 5 October 2011 01:19, Chris Lattner <clattner at apple.com> wrote: > I'm not sure what you're getting at here.  My email was not intended to say that I'm not interested in LLVM improving - quite the contrary.  My email was to rebut Dan's implicit claim that PNaCL and using LLVM as a portable IR is never going to work.  I'm arguing in the "opencl" and

On 5 October 2011 00:19, Chris Lattner <clattner at apple.com> wrote: > 1. The native client folks trying to use LLVM IR as a portable representation that abstracts arbitrary C calling conventions.  This doesn't work because the frontend has to know the C calling conventions of the target. (...) > 2. The OpenCL folks trying to turn LLVM into a portable abstraction language by

On Oct 4, 2011, at 4:42 PM, Renato Golin wrote: > On 5 October 2011 00:19, Chris Lattner <clattner at apple.com> wrote: >> 1. The native client folks trying to use LLVM IR as a portable representation that abstracts arbitrary C calling conventions. This doesn't work because the frontend has to know the C calling conventions of the target. > (...) >> 2. The OpenCL folks

Hi Talin, I too agree 100% with Dan's words, and this could be a good pointer for Jin-Gu Kang to continue on his pursuit for a better target-independent bitcode. Also, add your backwards compatibility issue to debug metadata in IR, in which fields appear or disappear without notice. But I think you hit a sweet spot here... On 4 October 2011 21:23, Talin <viridia at gmail.com> wrote:

Hello, [The first paragraph is safe to skip if you already know what PNaCl is.] The Portable Native Client (PNaCl) project is a toolchain for producing portable bitcode from C and C++ code and running in securely and efficiently on the web via Native Client. For more details see this presentation from the last Google I/O: https://developers.google.com/events/io/sessions/325679543and

Hi llvm list ! Everything is in the question. I've read this discussion on the mailinglist * [LLVMdev] LLVM IR is a compiler IR<https://groups.google.com/d/topic/llvm-dev/N3r_a1Vbrog/discussion> . * But since llvm3 and type system rewrite, is it a good idea to rethink about a VM wich could run the IR bytecode directly? llvm has differents bytecode from low level, to more hight level...

Hello, Following an earlier email ( http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/063010.html), we've published an initial version of the PNaCl bitcode reference manual online - http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl bitcode is a restricted subset of LLVM IR. The reference manual is quite terse, so for the bigger picture I'll repost links to the design

On Jul 18, 2012, at 2:39 PM, Pierre P <ploploplop123 at gmail.com> wrote: > Hi llvm list ! > > Everything is in the question. > I've read this discussion on the mailinglist [LLVMdev] LLVM IR is a compiler IR. > But since llvm3 and type system rewrite, is it a good idea to rethink about a VM wich could run the IR bytecode directly? The type system changes you mention

Hi, I am curious to know about LLVM IR as platform independent feature. I have compiler some C and C++ applications that compiled on Linux 64bit machine, now I want to generate bit code file on Windows 64bit machine. 1) Will this execute without any issues? 2) Do I pass any option for making it operating system portable? 3) Can I generate bit code file also on Linux machine and then run on

On Tue, Oct 4, 2011 at 6:36 PM, Renato Golin <rengolin at systemcall.org> wrote: > Hi Talin, > > I too agree 100% with Dan's words, and this could be a good pointer > for Jin-Gu Kang to continue on his pursuit for a better > target-independent bitcode. > > Also, add your backwards compatibility issue to debug metadata in IR, > in which fields appear or disappear

Hi all, Is it possible to merge two different languages in the same IR? With Java, JNI specifies a whole lot of rules to make C structures and PCS work with Java classes, if we were to do the same thing in IR, would that work? Is there anyone doing this today (with any language)? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at

On Jan 29, 2010, at 12:09 PM, Samuel Crow wrote: > Hello Russell, > > Major pitfall #1: > LLVM-GCC does certain optimizations even if all of the optimizations are turned off. These include endian-specific optimizations so to use LLVM as a cross-architecture bitcode, you'll need to wait until Clang supports C++ fully or just stick to C programs for now. > > I've been

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

On Oct 5, 2011, at 1:17 AM, Renato Golin wrote: > On 5 October 2011 01:19, Chris Lattner <clattner at apple.com> wrote: >> I'm not sure what you're getting at here. My email was not intended to say that I'm not interested in LLVM improving - quite the contrary. My email was to rebut Dan's implicit claim that PNaCL and using LLVM as a portable IR is never going to

The PNaCl project has implemented various IR simplification passes that simplify LLVM IR by lowering complex features to simpler features. We'd like to upstream some of these IR passes to LLVM. We'd like to explore if this acceptable, and if so, how we should go about doing this. The immediate reason is that Emscripten is reusing PNaCl's IR passes for its new "fastcomp"