similar to: [LLVMdev] Upstreaming PNaCl's IR simplification passes

On Tue, Mar 4, 2014 at 6:17 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Mar 4, 2014 at 1:04 PM, Mark Seaborn <mseaborn at chromium.org>wrote: > >> 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

On Tue, Mar 4, 2014 at 3:11 PM, Sean Silva <chisophugis at gmail.com> wrote: > On Tue, Mar 4, 2014 at 4:04 PM, Mark Seaborn <mseaborn at chromium.org>wrote: > >> 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

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

Hi Eli, Recently, I proposed some changes to LLVM to do more lowering of illegal types (like i128 or i17) and other things within the LLVM IR layer, and the proposal was roundly rejected by the LLVM community: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061567.html PNaCl is essentially doing what my proposal described. How do you expect to reconcile the community's desire to avoid

> > Just in case it gets lost in my longer reply, I want to emphasize that if > these will be used to simplify the in-tree backends and those backend > maintainers are on board, then I am *totally* in favor of this going into > the tree. My concerns are heavily based on the fact that as proposed, none > of that seems likely to happen. > > > Framing the problem

> On 2015 Mar 30, at 10:11, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon, Mar 30, 2015 at 9:52 AM Eric Christopher <echristo at gmail.com> wrote: > From PR18808 I said a few things and that I was going to redirect to the mailing list for further discussion. So here we are, go. > > 1) Whether or not to allow changing of

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

Thanks Mark! That'd be a useful starting point. For the rest of the people here: to be a bit more specific, I am having doubts about the following: - Can later optimization passes or code generation still create machine code that takes and stores (in a register perhaps) an address of something on the stack, even if not semantically visible to the programmer? Can this somehow be detected?

I haven't run out of popcorn watching the "Upstreaming PNaCl's IR simplification passes" thread but one thing struck me that I would really like clarified. It feels like a tangential issue so I thought I'd ask it separately. In the very same message, I see this: >>>> Some background:  There are two related use cases for these >>>> IR simplification

Hi all, Over the past couple weeks, I've been putting together a JavaScript backend for LLVM. At this point, I believe I've got reasonable implementations for all the instructions, primitives and derived types. I haven't gotten around to most of the intrinsics but I thought it would be a good idea to start getting some feedback before going much further. If anyone has the time and

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

On Tue, Dec 13, 2011 at 9:27 PM, Rafael Ávila de Espíndola < rafael.espindola at gmail.com> wrote: > > > $ llc bar.bc -filetype=obj -o bar.o > > $ clang -shared -o bar.so bar.o > > $ clang -use-gold-plugin foo.o bar.so -o t > > > > Is that correct? In particular, "lld t" should show a dependency on > bar. > > Any

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

> Is it more clear now? If not, I would like to give it another try and > write much more details and examples. I am still not completely sure I understand the use case. In particular since you say you want a bitcode module in the end, I don't understand how this is different from using llvm-link, it doesn't complain about undefined symbols... Can you provide an example? What are

Hello all, The rich history of binary distribution formats based on LLVM [0][1][2][3][4] has proven LLVM's viability as a launchpad for stable platforms. However, issues with compilation time and compiler size have suggested that the translator must do too much, i.e. LLVM IR isn't a low-level enough virtual machine. So we introduce DAGIR ("dagger"), a new portable close to the

I've been tossing around some ideas about high-level backends. Say, have LLVM emit Perl code. Sounds whacky but isn't. It's good for the first bootstrapping phase in environments where you don't have a C compiler, where you don't have a cross-compiled binary for download, but you can execute Perl. It also makes a great inspect-the-sources-with-an-editor stage for aspiring

On 02.01.2013, at 20:37, Alon Zakai wrote: > > > ----- Original Message ----- >> From: "Sebastian Redl" <sebastian.redl at getdesigned.at> >> >> It would be awesome to combine the llvm.org demo with the in-browser >> emscripten (or possibly a server-side emscripten) so that the user >> can execute his snippets in the browser. >>

On Oct 2, 2010, at 8:11 PM, David LaPalomento wrote: > Hi all, > Over the past couple weeks, I've been putting together a JavaScript > backend for LLVM. At this point, I believe I've got reasonable > implementations for all the instructions, primitives and derived > types. I haven't gotten around to most of the intrinsics but I thought > it would be a good idea to

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside,

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