similar to: [LLVMdev] Problems compiling llvm-gcc4 frontend on x86_64

Hi Warren, You have the -m32 flag set, but it's still giving you this: > Warning: Generation of 64-bit code for a 32-bit processor requested. > Warning: 64-bit processors all have at least SSE2. But are you sure you want to compile the LLVM-GCC source? You should use the binaries unless absolutely necessary. -bw On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: > Hi all,

Hi Warren, you can try to configure with the following export CFLAGS="-m64" export LDFLAGS="-L/usr/lib64" LLVM: ../src/configure --prefix=`pwd`../install --enable-optimized --enable-jit --enable-targets=host-only make LLVM-GCC: ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++

Here's a working testcase: ; ModuleID = '/tmp/crtbegin.bc' target datalayout = "E-p:32:32:128-i1:8:128-i8:8:128-i16:16:128-i32:32:128-i64:32:128-f32:32:128-f64:64:128-v64:64:64-v128:128:128-a0:0:128-s0:128:128" target triple = "spu" @__dso_handle = hidden global i8* null, align 16 ; <i8**> [#uses=0] @__CTOR_LIST__ = internal global [1 x void

Martin, Well, thanks for jumping in! We need all the help we can get ;) I changed the execute bit as you suggested and recompiled, no luck, still the same error message. Below is the output you wanted me to look at, its a bit beyond me so I include both a brief grep summary and then the whole enchilada. I do note that my output is different from yours, but I'm not sure how to interpret. I

Martin, Well, thanks for jumping in! We need all the help we can get ;) I changed the execute bit as you suggested and recompiled, no luck, still the same error message. Below is the output you wanted me to look at, its a bit beyond me so I include both a brief grep summary and then the whole enchilada. I do note that my output is different from yours, but I'm not sure how to interpret. I

Hi, While testing my new register allocators on some test-cases, I've noticed that LLVM misses sometimes some optimization opportunities: 1) LocalSpiller::RewriteMBB seems not to propagate the information about e.g. Spills between MBBs.In many cases, where MBB B1 has only one predecessor MBB B2, B1 could reuse the information about the physical registers that are in the live-out set of B2.

I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. >>> cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor&

Andrew Purtell wrote: > I routinely fetch the latest LLVM and LLVM-GCC4 and recompile, perhaps every few days or so. I've not had success in some cases building LLVM-GCC4 on a Gentoo Linux host, for perhaps the last week or so. My system compiler is GCC 4.1.1. > > > cc1: /usr/src/llvm/llvm/include/llvm/Target/TargetInstrInfo.h:151:const llvm::TargetInstrDescriptor&

I thought I'd share a little bit of progress I made this weekend. I've gotten the first interesting test-case (a simple switch) through hyperblock-based DAGISel, and there's a pretty picture too! Each part of the switch is emitted directly into the DAG, rather than being deferred. This is the function: define i32 @foo(i32 %x, i32 %z) nounwind { entry: switch i32 %x,

> On May 17, 2016, at 1:33 AM, Shi, Steven via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > Let me ask a LTO simple question again. For the llvm LTO example in the link:http://llvm.org/docs/LinkTimeOptimization.html <http://llvm.org/docs/LinkTimeOptimization.html>, I use below build commands to generate three different optimization level binary: -O0, -O1, -O2.

Thanks. Can you file bugzilla reports? I'll look at the first one soon. Evan On Feb 5, 2009, at 8:08 AM, Roman Levenstein wrote: > Hi, > > While testing my new register allocators on some test-cases, I've > noticed that LLVM misses sometimes some optimization opportunities: > > 1) LocalSpiller::RewriteMBB seems not to propagate the information > about e.g. Spills

Hi all, Working on lld aarch64 support I came across an issue where I am not sure which would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at

Hi Umesh, Thank you for the suggestion. I can use the "Brute force method " to narrow down the LTO wrong instructions here and there, but I still don't know why these wrong instructions are generated, and how to let Clang LTO don't generate those wrong instructions. I suspect the wrong code is caused by some LTO wrong optimization pass, so I hope to disable all optimizations in

According to the docs, InsertBranch should only be called if AnalyzeBranch returns success. But in targets (like ARM or Sparc) that don't implement them, the following test fails: ----------------------------------- void %__gcov_init() { entry: switch uint 0, label %cond_true.i [ uint 0, label %UnifiedReturnBlock uint 875573313, label

Very nice! Why did you decide on hyperblock instead of SEME region and how are you forming the blocks? Evan On Apr 20, 2008, at 9:59 PM, Christopher Lamb wrote: > I thought I'd share a little bit of progress I made this weekend. > I've gotten the first interesting test-case (a simple switch) > through hyperblock-based DAGISel, and there's a pretty picture too! >

Hi all, I recently downloaded the gcc 4 frontend from: http://llvm.org/releases/1.8/llvm-gcc4-1.8-x86-linux.tar.gz I checked out the source from CVS using: cvs -d :pserver:anon at llvm.org:/var/cvs/llvm login cvs -z3 -d :pserver:anon at llvm.org:/var/cvs/llvm co llvm Running the configure script fails to find llvm-gcc. Inspecting the untarred frontend, it doesn't contain any such binary,

Hi all, I'm looking into using LLVM to do some optimisations of Fortran code. As part of this, I've been trying to build the frontend with f95 support. At the moment, I'm trying to resolve undefined symbol problems for code defined in c-common.c + elsewhere - I'm taking the temporary approach of copy-pasting it into a new file, and linking that in. I have no idea if it will

On 11/8/06, Warren Armstrong <warren.armstrong at anu.edu.au> wrote: > Hi all, > > I'm looking into using LLVM to do some optimisations of > Fortran code. As part of this, I've been trying to build > the frontend with f95 support. At the moment, I'm trying > to resolve undefined symbol problems for code defined in > c-common.c + elsewhere - I'm taking

2009/1/13 Evan Cheng <echeng at apple.com>: > > On Jan 7, 2009, at 2:48 AM, Roman Levenstein wrote: > >> bb368: 0x8fdad00, LLVM BB @0x8fc2c98, ID#1: >> Predecessors according to CFG: 0x8fdac90 (#0) >> %R0<def> = MOVi 0, 14, %reg0, %reg0 >> *** STR %LR<kill>, %R0<kill>, %reg0, 0, 14, %reg0, Mem:ST(4,4) >> [0x8fc2d68 + 0]

Hi, I'm working on the iterated register coalescing graph coloring allocator and try to test it with all backends available currently in LLVM. Initial tests with most of the backends are successful. It turned out that my allocator triggers a specific assertion in the RegScavenger and only for the ARM target. It looks like the LR register is used for frame pointer related things, but it is