similar to: [LLVMdev] LTO, Code Generation Options, etc

> 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

On 2016-08-26 12:47, Mehdi Amini wrote: >> On Aug 26, 2016, at 9:06 AM, junbuml at codeaurora.org wrote: >> >> On 2016-08-26 11:32, Mehdi Amini wrote: >>> Hi, >>>> Recently, I noticed that less number of global variables are merged >>>> in global-merge pass and in some global variable, array types are >>>> used instead of its

> On Mar 7, 2016, at 9:43 AM, Adam Nemet <anemet at apple.com> wrote: > > Hi Haicheng, > > Sorry about the breakage. I reverted it in r262839. > > I will try to reproduce it locally. Please don’t blow away your directories yet in case I need further help. OK, I managed to reproduce this locally. Should be able to make progress from here without further help from

Hi Adam, I find LoopLoadElimination (r262250) causes SPEC2006/gcc generate wrong result (166.s) in AArch64 when running with *ref* data set. The error happens when I use either "-Ofast -flto -fuse-ld=gold" or "-O3 -fno-strict-aliasing". Please let me know if you need more information. Best, Haicheng -------------- next part -------------- An HTML attachment was

On Thu, Mar 10, 2016 at 1:17 AM, Adam Nemet <anemet at apple.com> wrote: > I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys > please give it a test with your codebase. (You need to enable the pass with > -mllvm -enable-loop-load-elim.) The miscompilation I was seeing is gone now, too. Thanks! > On Mar 7, 2016, at 11:05 PM, Adam Nemet <anemet at

Thanks for the test case! I can reproduce this, and see with the compiler I saved from just before r278338 that this is indeed a chance in behavior. Looking at why this changed... On Fri, Aug 26, 2016 at 1:42 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Aug 26, 2016, at 1:34 PM, junbuml at codeaurora.org wrote: >> >> On 2016-08-26 12:47, Mehdi Amini wrote:

# The future of the va_arg instruction ## Summary LLVM IR currently defines a va_arg instruction, which can be used to access a vararg. Few Clang targets make use of it, and it has a number of limitations. This RFC hopes to promote discussion on its future - how 'smart' should va_arg be? Should we be aiming to transition all targets and LLVM frontends to using it? ## Background on va_arg

Try as I might I can't seem to get LLVM to bulid using clang/clang++. No matter what I do it insists on using /usr/bin/cc and /usr/bin/c++ which are gcc. Am I missing something obvious? I vaguely remember some document describing a stage1 compiler built by your old toolchain and a stage2 compiler but I can't find the steps to do that any more. $ CC=/usr/local/bin/clang

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

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

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

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, Can someone who's familiar with lld take a look? [2980/3371] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/disassemble.c.o [2981/3371] Building CXX object tools/lld/COFF/CMakeFiles/lldCOFF.dir/Writer.cpp.o FAILED: tools/lld/COFF/CMakeFiles/lldCOFF.dir/Writer.cpp.o /opt/arm/arm-linux-compiler-20.0_Generic-AArch64_RHEL-7_aarch64-linux/bin/armclang++ -DGTEST_HAS_RTTI=0

> On Aug 26, 2016, at 2:06 PM, Teresa Johnson <tejohnson at google.com> wrote: > > Mehdi: I see what is going on: > > + ArrayType *Ty = > + ArrayType::get(Type::getInt8Ty(RegularLTO.Ctx), I.second.Size); > + GlobalVariable *OldGV = RegularLTO.CombinedModule->getNamedGlobal(I.first); > + if (OldGV && OldGV->getType()->getElementType()

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 >

Hi Renato, If Kristof is busy I can make runs on AArch64 Linux (Cortex-A53 and Cortex-57). Thanks, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Renato Golin via llvm-dev > Sent: Thursday, March 30, 2017 9:54 AM > To: Quentin Colombet > Cc: llvm-dev;

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

I'm trying to understand why using a local memcpy with LTO results in a "multiple definition" error. I have an local (optimized) mempy.c (clearly simplified!): void* memcpy(void* dest, const void* src, unsigned int count) { return 0; } void* __aeabi_memcpy(void *dest, const void *src, unsigned int size) { return memcpy(dest,src,size); } --- I also have a simple