similar to: [LLVMdev] The target independence of IR

All, I should have chimed in earlier, but have been working on two more side-channel variants of this conversation. At the beginning the PNaCl team was strongly pushing for trying to keep platform ABI compatibility on all platforms while taking one portable bitcode stream as input. During the discussions we've had over the past few weeks it became obvious that that is simply not tractable,

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

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

Hi all, If it's not the right place to ask, please forgive me. Currently I'm working on a new operating system concept, called "Om". The first feature would be Android-like apps, coming in *.opk files that would contain all needed resources and source-code expressed in LLVM-IR assembly language. http://sett.com/openminded-os/uid/88508 How does it sound ? Julien

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

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

Dear LLVM members. I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version. When i compiled 'od' program in coreutils package using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc:

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"

I'm in the process of teaching the Verifier to validate that the size of debug info variable and the described value matches (already caught a couple of bugs, both in my frontend and in LLVM itself). However, I've run into the following: size of passed value (80) does not match size of declared variable (128) call void @llvm.dbg.declare(metadata x86_fp80* %x, metadata !11, metadata

Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you're using a copy of llvm-gcc that was built to generate x86 code. On Sep 30, 2009, at 6:27 AM, Jin Gu Kang wrote: > Dear LLVM members. > > I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 > version. > > When i compiled 'od' program in

Hi Jin-Gu Kang! It are possible that the problem you are experiencing have already been solved in the current llvm 2.6 release tree and the current svn trunk. So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk! It would be helpful if you could open a bugreport for this issue and attach the problematic od.bc since we need a testcase from the bitcode that exposes the bug inorder

Hi Bob! I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code. $llvm-gcc-src/gcc/config.gcc file alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes # LLVM LOCAL begin out_cxx_file=alpha/llvm-alpha.cpp # LLVM LOCAL end ;; ... arm*-*-*) cpu_type=arm extra_headers="mmintrin.h" ;; ... i[34567]86-*-*) cpu_type=i386 # LLVM LOCAL begin

Hi Micah, Thanks a lot for the reference. Unfortunately, it looks like the discussion there is dealing with a somewhat different issue - modeling OpenCL address spaces. It's true that the null pointer issue may arise in a similar context (e.g. null pointers in different address spaces may have different internal representations), but it's not entirely related. Or have I missed something

Hi In my previous mail I mentioned the project on KCoFI( the control FLow integrity methods for commodity hardware http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ). Will it be more helpful to the community if I do the improvements number #1 and #3 mentioned in my previous mail to the mailing list or if i try to port it to arm architecture? I have decided to go ahead with the improvements

That was essentially part of my question. The DWARF standard says: If the value of an object of the given type does not fully occupy the > storage described by a byte size attribute, the base type entry may also > have a DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose > values are integer constant values (see Section 2.19). The bit size > attribute describes the

Hi, I've been hacking around something missing in the assemble for the mingw-w64 targets the tfloat variable. I did some research into the llvm sources and did see x86_fp80 which seems to be the same thing. Can we support the .tfloat variable or the alternative ? Or is it under another name? I've tried using .x86_fp80 instead but to no avail. :/ Here is how tfloat is being used in

On 24 Oct 2014, at 18:17, Renato Golin <renato.golin at linaro.org> wrote: > I'm beginning to think that the "nice" feature 1 is not worth the two > big problems 2 and 3. If we tie Clang builds with back-end builds and > force it not to have support for other arches (because the info isn't > available if you don't build its back-end), than all that info can

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

That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn't work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know. For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc. On Sep 30, 2009,