similar to: [LLVMdev] comparing -O5 to -std-compile-opts

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

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

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

As a follow up, if I first convert x.bc to a c file using llc -march=c -o x.c x.bc, and then I use normal gcc to convert x.c to an executable, f() remains a global symbol. Is llvm-nm incorrectly converting the global symbols to local symbols? Ryan M. Lefever wrote: > I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a > function f(), that I've written, is

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

I have a bitcode file x.bc. When I run llmv-nm on x.bc, it shows that a function f(), that I've written, is defined as a global function (text) object, i.e., llvm-nm shows it marked with a 'T'. I have converted x.bc to an executable with the following command: llvm-ld -native -o x.exe x.bc When I run nm on x.exe, it shows that f is now a local function (text) object, i.e., nm

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

I assume that when -O3 (or O2 or O1) is passed to llvm-gcc, then it utilizes opt. How do I determine what passes opt runs? How do I determine what external tools (and arguments) llvm-gcc is invoking? Regards, Ryan

In a previous post (included at the end of the message), Reid stated that in August 2006, llvm-ld did not support native libraries. I have a few questions about that. Is it still true that llvm does not support native libraries? Furthermore, what exactly is meant by that? In particular, I have bytecode that I want to turn into a native executable and it needs to be linked against a dynamic

Can I specify passes that I want run directly to llvm-gcc? I don't want all of -O3, for example. I tried llvm-gcc -raiseallocs ..., but that didn't work. I also tried running cc1 directly and it didn't take -raiseallocs as a parameter either. Duncan Sands wrote: > On Tuesday 28 April 2009 04:02:47 am Ryan M. Lefever wrote: >> I assume that when -O3 (or O2 or O1) is

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

Hi Ryan, On Sat, 2007-03-31 at 18:33 -0500, Ryan M. Lefever wrote: > In a previous post (included at the end of the message), Reid stated > that in August 2006, llvm-ld did not support native libraries. I have a > few questions about that. Is it still true that llvm does not support > native libraries? Furthermore, what exactly is meant by that? llvm-ld has been worked on (by

On my 32 bit linux box, things seam to work find, but on my 64 bit linux box I am getting problems. I have the following c file (lib.c): -------------------------------- #include <stdio.h> void libmethod(){ printf("libmethod()\n"); } ------------------------------- I tried to get a shared library using the following commands: llvm-gcc -emit-llvm -Wall -fPIC -c -o lib.opt.bc

Folks, 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 week. For clarity, the -O options are currently defined

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

I followed what you said and called verifyModule() with the AbortProcessAction option. verifyModule() returns false, but does not abort and does not print out any information about what caused the verification to fail. Chris Lattner wrote: > On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >> I am writing an interprocedural compiler pass. Because the passneeds >> information from a

Does llvm-gcc support the -fPIC option? I am using LLVM on both 32 bit linux and 64 bit linux, if that matters. Regards, Ryan -- Ryan M. Lefever [http://www.crhc.uiuc.edu/~lefever/index.html]

I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt if

Hi folks, I've got an idea for something I may be able to do as a Link-Time- Optimization pass, but I can't seem to find how LTO gets used. My crude approach has been to compile LLVM for debugging, and then run gdb on llvm-ld with -O5 and two .bc files, trying to catch LTO in action. I've also scanned the compiled tools, and none of them appear to use the symbol

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