similar to: [LLVMdev] Optimization Levels - Need The Details

On Sat, 14 Aug 2004, Reid Spencer wrote: > I'm at the point in developing llvmc (Compiler Driver) where I need to > get the details on the specific optimization arguments that the -O > family of options should (by default) issue to "opt". I'm soliciting > your feedback on this so I can start testing optimization. Hopefully you > can provide it by early this coming

Reid, I have one substantial change to suggest to this. I think the distinction between module-level and cross-module optimization is artificial and unnecessary in LLVM because transparent link-time optimization makes intra-module and cross-module optimizations indistiguishable. It *is* important to distinguish between fast and slow optimizations. Because of this, I would suggest a

On Sat, 2004-08-14 at 21:00, Chris Lattner wrote: > On Sat, 14 Aug 2004, Reid Spencer wrote: > > > I'm at the point in developing llvmc (Compiler Driver) where I need to > > get the details on the specific optimization arguments that the -O > > family of options should (by default) issue to "opt". I'm soliciting > > your feedback on this so I can

Hello, When I run LLC with option "-O0 -march=sparc" on following testcase, fast register allocator crashes with "UNREACHABLE executed" error. LLC generates code successfully with other standard register allocators available. $ cat call.ll define void @test() nounwind { entry: %0 = tail call i32 (...)* @foo() nounwind tail call void (...)* @bar() nounwind ret void }

On Oct 8, 2011, at 12:05 PM, Duncan Sands wrote: > PS: With -fplugin-arg-dragonegg-enable-gcc-optzns the LLVM optimizers are run at > the following levels: > > Command line option LLVM optimizers run at > ------------------- ---------------------- > -O1 tiny amount of optimization > -O2 or -O3 -O1 > -O4 or -O5

Hi Chris, >> PS: With -fplugin-arg-dragonegg-enable-gcc-optzns the LLVM optimizers are run at >> the following levels: >> >> Command line option LLVM optimizers run at >> ------------------- ---------------------- >> -O1 tiny amount of optimization >> -O2 or -O3 -O1 >> -O4 or -O5

On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote: > When I run LLC with option "-O0 -march=sparc" on following testcase, > fast register allocator crashes with "UNREACHABLE executed" error. LLC > generates code successfully with other standard register allocators > available. I haven't investigated the Sparc backend specifically but... My guess is

On Aug 24, 2007, at 1:52 PM, Holger Schurig wrote: > Is llvmc meant for compilation? > I'm not sure what the status of llvmc is (is anyone working on it?), but I don't believe it was ready for real use or was finished. If you would like to work on it, patches are welcomed! Thanks, Tanya > $ llvmc -c a.c -o a.o > /usr/src/llvm/dist/etc/llvm/c:55: Error: Expecting output

Is llvmc meant for compilation? $ llvmc -c a.c -o a.o /usr/src/llvm/dist/etc/llvm/c:55: Error: Expecting output type value /usr/src/llvm/dist/etc/llvm/c had 1 errors. Terminating. The offending line contains: optimizer.output = bytecode which doesn't seem to be understood by llvmc. If I uncomment this line, I get another error message: $ llvmc -c a.c -o a.o llvmc: Can't find program

The Polyhedron 2005 benchmark results for dragonegg svn at r141492 using FSF gcc 4.6.2svn measured on x86_64-apple-darwin11 are listed below. The benchmarks used the optimizaton flags... -msse4 -ffast-math -funroll-loops -O3 in all cases. The use of -fplugin-arg-dragonegg-enable-gcc-optzns to allow for autovectorization from the FSF gcc front-end only produces a single run-time regression,

Hi Jack, > The Polyhedron 2005 benchmark results for dragonegg svn at r141492 > using FSF gcc 4.6.2svn measured on x86_64-apple-darwin11 are listed below. > The benchmarks used the optimizaton flags... > > -msse4 -ffast-math -funroll-loops -O3 > > in all cases. The use of -fplugin-arg-dragonegg-enable-gcc-optzns to allow > for autovectorization from the FSF gcc

From: Evgeny Kravtsunov <emkravts@openvz.org> compare_ether_addr() implicitly requires that the addresses passed are 2-bytes aligned in memory. This is not true for br_stp_change_bridge_id() and br_stp_recalculate_bridge_id() in which one of the addresses is unsigned char *, and thus may not be 2-bytes aligned. Signed-off-by: Evgeny Kravtsunov <emkravts@openvz.org> Signed-off-by:

On 04/10/2010 08:01 PM, Jack Howarth wrote: > > bash-3.2$ GCC=/sw/bin/gcc-4 CC=gcc-4 CXX=g++-4 CFLAGS=-I/sw/include CXXFLAGS=-I/sw/include LLVM_CONFIG=/sw/lib/llvm/bin/llvm-config make > g++-4 -c -I/sw/lib/llvm/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -MD -MP -DIN_GCC -DREVISION=\"100954M\"

I have updated the klibc patchset based on feedback received. In particular, the patchset has been reorganized so as not to break git-bisect. Additionally, this updates the patch base to 2.6.17-git12 (d38b69689c349f35502b92e20dafb30c62d49d63) and klibc 1.4.8; the main difference on the klibc side is removal of obsolete code. This is also available as a git tree at:

I tried llvm-gcc -c test.c llvm-gcc test.o llc -march=c test.bc -f -o test2.c Then I compiled both test.c and test2.c with sdcc, a compiler which lacks high-level optimization. The code generated from test2.c was bigger. Then I tried llvm-gcc -O5 -Os -c test.c llvm-gcc -O5 -Os test.o llc -march=c test.bc -f -o test2.c But it generated exactly the same code as the commands above. What is it that

On Sat, Apr 10, 2010 at 01:52:18PM +0200, Duncan Sands wrote: > Hi Jack, > > > Is anyone building dragon-egg on darwin? > > Anton built it once. There were some problems with dynamic libraries: gcc's > plugin support requires the use of dynamic libraries, and the configure logic > it uses thinks that darwin does not support dynamic libraries! So it is >

Hi LLVM, I am using 3.0, and I have a question about the __thread in c and thread_local in LLVM IR: O1-O4 and the final linked code behave differently. //////////////////////////////////// The following C code is from the LLVM testcase (SingleSource/UnitTests/Threads/2010-12-08-tls.c) #include <stdio.h> __thread int a = 4; int foo (void) { return a; } int main (void) {

This has been an idea floating around in my head for a while and after several discussions with others it continues to hold up so I thought I would mail it out. Sorry for cross posting to both lists, but this is an issue that would significantly impact both LLVM and Clang. Essentially, LLVM provides canned optimization "levels" for frontends to re-use. This is nothing new. However, we

Actually, Misha, that won't work. The -C option is used directly in docs/Makefile. So the change will have to go into docs/Makefile. Either that or upgrade install to version 5. Reid. On Thu, 2005-02-17 at 11:33, Misha Brukman wrote: > On Thu, Feb 17, 2005 at 01:21:20PM -0600, Feng Chen wrote: > > llvm[1]: Installing HTML documentation > >

Ryan Brown wrote: > I don't think llvm-gcc4 uses gccas or gccld, but it can emit bytecode > if you give it the --emit-llvm option: > llvm-gcc --emit-llvm -c -o foo.bc foo.c That's a bit asymmetric with the previous gcc3 version, isn't it? That would mean that the "An Example Using the LLVM Tool Chain" section needs to be updated for the gcc4 frontend. OTOH, I could