search for: native_client

...hey are already maintaining a couple of forks of BitstreamReader [1] so it would appear that the only change necessary on their side would be to also fork the interfaces. If you are aware of any other significant users, please speak up! Thanks, -- -- Peter [1] https://chromium.googlesource.com/native_client/pnacl-llvm/+/master/ include/llvm/Bitcode/NaCl/NaClBitstreamReader.h https://chromium.googlesource.com/native_client/pnacl-subzero/+/master/pnacl-llvm/include/llvm/Bitcode/NaCl/NaClBitstreamReader.h -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llv...

...itstreamReader [1] so it > would appear that the only change necessary on their side would be to also > fork the interfaces. > > If you are aware of any other significant users, please speak up! > > Thanks, > -- > -- > Peter > > [1] https://chromium.googlesource.com/native_client/pnacl- > llvm/+/master/include/llvm/Bitcode/NaCl/NaClBitstreamReader.h > https://chromium.googlesource.com/native_client/pnacl-subzero/+/master/ > pnacl-llvm/include/llvm/Bitcode/NaCl/NaClBitstreamReader.h > -- -- Peter -------------- next part -------------- An HTML attachment was...

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 want to see the code and the diff against upstream, our LLVM repo is in https://gerrit.chromium.or...

...he only change necessary on their side would be to also fork >> the interfaces. >> >> If you are aware of any other significant users, please speak up! >> >> Thanks, >> -- >> -- >> Peter >> >> [1] >> https://chromium.googlesource.com/native_client/pnacl-llvm/+/master/include/llvm/Bitcode/NaCl/NaClBitstreamReader.h >> https://chromium.googlesource.com/native_client/pnacl-subzero/+/master/pnacl-llvm/include/llvm/Bitcode/NaCl/NaClBitstreamReader.h > > > > > -- > -- > Peter

...;mov2 mov3" cannot cross a > bundle boundary, 9 bytes of NOP padding will be inserted between mov1 > and mov2. > > For information on how this ability is used for software fault > isolation by Native Client, see the following resources: > > * http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf[PDF link] > * > http://www.chromium.org/nativeclient/reference/arm-overview#TOC-The-Native-Client-Solution:-Bundles- > * Other papers listed at > http://www.chromium.org/nativeclient/reference/research-papers > > We want to start with this feature because it...

...-Greg On Tue, Dec 4, 2012 at 9:03 PM, Derek Schuff <dschuff at google.com> wrote: > 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 want to see the code and the diff against upstream, > our LLVM repo is in &...

...the bundle-locked sequence "mov2 mov3" cannot cross a bundle boundary, 9 bytes of NOP padding will be inserted between mov1 and mov2. For information on how this ability is used for software fault isolation by Native Client, see the following resources: * http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf [PDF link] * http://www.chromium.org/nativeclient/reference/arm-overview#TOC-The-Native-Client-Solution:-Bundles- * Other papers listed at http://www.chromium.org/nativeclient/reference/research-papers We want to start with this feature because it is self-contained in MC, ma...

...fining the variables/flags/etc., to allow selecting the x32 ABI in LLVM. We are aware of the previous set of patches posted to this list for x32, and will be as consistent with that direction as possible. For background, the x8-64 Native Client model is described in http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf x32 is described at https://sites.google.com/site/x32abi/ The previous set of patches was sent attached to http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120604/144037.html Cheers, David -------------- next part -------------- An HTML attachment was scrubbed....

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 cisco.com>: > Is it just an optimization pass? Maybe I can ca...

...gs/etc., to allow selecting the x32 ABI in LLVM. We > are aware of the previous set of patches posted to this list for x32, > and will be as consistent with that direction as possible. > > For background, the x8-64 Native Client model is described in > http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf > x32 is described at https://sites.google.com/site/x32abi/ > The previous set of patches was sent attached to > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120604/144037.html > > Cheers, > > David > -------------- next part ----...

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 >

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

> 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,

Marcus Zetterquist <marcus.zetterquist at gmail.com> writes: > Today we use Lua to let 3rd party developers add driver-like modules > to our application. > > The advantages to using Lua compared to DLL:s etc. are that: > > 1) the same driver binary can be used on all OS:es and processor > architectures etc. [snip] > I'm looking into using LLVM and the

...ov2 mov3" cannot cross a > bundle boundary, 9 bytes of NOP padding will be inserted between mov1 > and mov2. > > For information on how this ability is used for software fault > isolation by Native Client, see the following resources: > > * http://src.chromium.org/viewvc/native_client/data/site/NaCl_SFI.pdf [PDF link] > * http://www.chromium.org/nativeclient/reference/arm-overview#TOC-The-Native-Client-Solution:-Bundles- > * Other papers listed at > http://www.chromium.org/nativeclient/reference/research-papers > > We want to start with this feature because it is...

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

...ndependent of each other -- so they allow projects to pick and choose which IR features to support and which to pre-lower. The modularity of these passes makes them low-maintenance and easy to write targeted tests for. The code for these passes can be found here: https://chromium.googlesource.com/native_client/pnacl-llvm/+/master/lib/Transforms/NaCl/ There seems to be plenty of precedent for IR-to-IR lowering passes -- LLVM already contains passes such as LowerInvoke, LowerSwitch and LowerAtomic. The PNaCl team (which I'm a member of) is happy to take on the work of maintaining this code, such as u...

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?

Hi! Today we use Lua to let 3rd party developers add driver-like modules to our application. The advantages to using Lua compared to DLL:s etc. are that: 1) the same driver binary can be used on all OS:es and processor architectures etc. 2) We can provide a small API to the Lua drivers and they _cannot_ call any other external functions. 3) A buggy driver cannot crash our application.

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