similar to: RFC: Removing the DataStreamer and MemoryObject interfaces

And on a separate thread [0] Derek indicated he'd be fine with removing it. I'll leave this thread open until end of Monday to receive any other opinions, then proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > >

Awesome! Thanks, Rafael On 28 October 2016 at 13:14, Peter Collingbourne <peter at pcc.me.uk> wrote: > And on a separate thread [0] Derek indicated he'd be fine with removing it. > I'll leave this thread open until end of Monday to receive any other > opinions, then proceed to remove it. > > Peter > > [0] >

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

Hi Greg, Our repos are public already, hosted on the Chromium infrastructure. Our builds are based out of the Native Client repository. The nacl git mirror is at http://git.chromium.org/native_client/src/native_client.git (no gitweb, sorry). That repo has pointers to a bunch of other repos which make pnacl (LLVM, clang, binutils, and a few others. see the file pnacl/DEPS for more). But if you just

Is it just an optimization pass? Maybe I can cancel it somehow with a flag or by doing some code editing? Can you point me to which passes may do that? I'm working on editing a backend that can't work with anything larger than 32 bits. Does the legalize stage work on IR code? Maybe i can use that? On Jan 29, 2015 5:41 AM, Ruiling Song <ruiling.song83 at gmail.com> wrote: LLVM

Hi Eli, > we are splitting the effort to manageable chunks that can > be committed, tested and reviewed separately as > independently as feasible I'd be interested in experimenting with this stuff sooner than later. Could you dump all the patches in a publicly accessible repo? How about Github? Thanks, Greg On Tue, Dec 4, 2012 at 3:53 PM, Eli Bendersky <eliben at

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

Hi Rafael, We will try out your patch and check to see how it will fit. You also talked about "It might be even possible to drop the requirement for the size to be known: Replace the call to AtEndOfStream by just trying to read more and checking if it failed, but that is a bit more than I wanted to do for this." That is to remove some calls to getSize()? Is there any expectation that

Generally legalize at IR level is not a good idea. But if you need legalization on IR code, you can check PNaCl project. https://chromium.googlesource.com/native_client/pnacl-llvm/ The pass is located at: lib/Transforms/NaCl/ExpandLargeIntegers.cpp You need make some change, as the pass split large integer into 64bit integers. 2015-01-29 16:06 GMT+08:00 Alon Shaltiel (ashaltie) <ashaltie at

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"

Hello, We (the Portable Native Client team) would like to start upstreaming our LLVM modifications which contain support for Software Fault Isolation (SFI) as required for sandboxing programs to run under Native Client. Since the "total patch size" is quite big, we are splitting the effort to manageable chunks that can be committed, tested and reviewed separately as independently as

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

Hi Rafael, Would you mind waiting for Derek to come back from vacation to discuss this? We do use this code and could improve how it's used and tested within LLVM. Derek is the best person to discuss this, he'll be back in mid-January. Thanks, JF On Fri, Dec 19, 2014 at 6:41 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > > I CC'ed llvmdev to put a

Hi Danny, On 2007-12-26, at 15:39, Danny wrote: > I've noticed that the BitcodeReader appears to be an internal > module, but the BitstreamReader is public. Should I be using the > BitstreamReader? If so how. The generic BitstreamReader class is public because it's used in other projects, including clang, to serialize data structures other than LLVM IR. The coding of

Hey there, I'm relatively new to the llvm scene, and so far I'm liking it quite a bit. I'm a bit perplexed as to what llvm-gcc's role is in everything. I've used it to create .bc files for really simple functions and it seems to do quite well at that, but I've been trying to figure out how to take the output from llvm-gcc and actually use it in another program.

That worked quite well. Thank you. One question as a follow up: is there a nice/standard way of including the pre-made bitcode chunks in with the binaries that are being created which read them? Bascially, I'd like to have the same functionality, but rather than having one or more .bc files running around which need to be read at runtime by an executable, moving that into the code

Hi all, This is about https://reviews.llvm.org/D26100 That change moves the block info block state from BitstreamReader to BitstreamCursor in order to accommodate multiple block info blocks (the idea is that the cursor would store the block info block state for whichever block info block is active for that cursor). Duncan objected to it on the grounds that we should aim for a design that would

> On Oct 28, 2016, at 6:00 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > This is about https://reviews.llvm.org/D26100 <https://reviews.llvm.org/D26100> > > That change moves the block info block state from BitstreamReader to BitstreamCursor in order to accommodate multiple block info blocks (the idea is that the cursor would store the

> On 2016-Oct-31, at 20:30, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Oct 28, 2016, at 6:00 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi all, >> >> This is about https://reviews.llvm.org/D26100 >> >> That change moves the block info block state from BitstreamReader to BitstreamCursor in order to