similar to: [LLVMdev] PNaCl Bitcode reference manual

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

On 2013-07-30 22:11, Eli Bendersky wrote: > 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. > > Any comments would be most welcome. Hi Eli, I appreciate you for opening the process for input and comments. One question stood

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

> The document is available as a PDF here: > https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo0OWYwZjVkYWFjOWNjODE1 > > And in text here: > https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/stability-of-the-pnacl-bitcode-abi First, sorry for jumping in an old thread. I had this marked but had not been able to read it

On 1 August 2013 00:11, Travis Cross <tc at travislists.com> wrote: > On 2013-07-30 22:11, Eli Bendersky wrote: > > 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. > > > > Any comments would be

Is it possible to use PNaCl infrastructure (i.e. translation and execution in a sandbox) without a Chrome ? I mean a something like a standalone VM like Java or Mono/C#. Dmitri Am 18.06.2013 17:22, schrieb Eli Bendersky: > 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

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

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, but the document does not

On 18 June 2013 15:27, Dmitri Rubinstein <dmitri.rubinstein at googlemail.com>wrote: > Is it possible to use PNaCl infrastructure (i.e. translation and execution > in a sandbox) without a Chrome ? > > I mean a something like a standalone VM like Java or Mono/C#. > Yes. The NaCl tool 'sel_ldr' will run a program inside a sandbox outside of the web browser. We do a

Hi Mark, On 2013-08-02 04:11, Mark Seaborn wrote: > That note in the documentation seems to be incorrect, because LLVM > will do tail call optimisations on at least x86 when using the "ccc" > calling convention. For example: > > $ cat tail_call1.c > void foo(int arg); > void bar(int arg) { > foo(arg); > } > > $ clang tail_call1.c -S -o - -O2 >

I'm not familiar with PNaCl but, FWIW, I'd say the three main advancements the CLR made over the JVM are: . Structs (aka value types). . Reified generics. http://research.microsoft.com/pubs/64031/designandimplementationofgenerics.p df . Tail call elimination. http://research.microsoft.com/pubs/69132/babel01.pdf Structs give you more freedom around memory

On Wed, Jul 31, 2013 at 11:55 PM, Travis Cross <tc at travislists.com> wrote: > On 2013-07-30 22:11, Eli Bendersky wrote: > > 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. > > > > Any comments

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

We (PNaCl team) are in the process of removing older documentation, this is probably more accurate: https://developers.google.com/native-client/dev/ On Tue, Dec 17, 2013 at 6:50 AM, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Check out PNaCL > http://www.chromium.org/nativeclient/pnacl > > Cheers, > Sam > > Sam Parker > Research Student > Electronic Systems

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"

Thanks, I hadn't heard about PNaCl, it's very interesting. I'm currently swimming in http://llvm.org/docs/ trying to learn more about LLVM-IR... Selon JF Bastien <jfb at google.com>: > We (PNaCl team) are in the process of removing older documentation, > this is probably more accurate: > https://developers.google.com/native-client/dev/ > > On Tue, Dec 17,

On May 31, 2011, at 7:36 PM, Samuel Crow wrote: <snip> >> >> Now my idea for a whacky backend: Just a wrapper of the bitcode writer with its >> own special target triple: bitcode-tarrget-neutral and a generic data layout >> that aligns to single bytes as a placeholder only. It should disallow >> overriding the alignment of individual instructions to avoid

Check out PNaCL http://www.chromium.org/nativeclient/pnacl Cheers, Sam Sam Parker Research Student Electronic Systems Design Group Loughborough University UK ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of mindmachine at free.fr [mindmachine at free.fr] Sent: 17 December 2013 14:03 To: llvmdev at cs.uiuc.edu Subject:

Hi all, LLVM/Clang supports an OS called 'NaCl' (llvm/include/llvm/ADT/Triple.h). It apparently hasn't had any development since 2015. This page https://developer.chrome.com/native-client/migration mentions that NaCl is deprecated. Is it still used? If not, I would propose that we remove it. I created a patch https://reviews.llvm.org/D78441 which I think can delete 90% of the