similar to: [LLVMdev] Is -m32 supported by llvm-gcc when using LTO/gold?

On 30 August 2010 12:43, Luke Dalessandro <luked at cs.rochester.edu> wrote: > I have gold from cvs, and llvm-gcc/llvm from svn. My platform is > Ubuntu 9.04 x86_64. I've configured llvm-gcc with "--enable-multilib". > > When compiling the LTO example from > http://llvm.org/docs/LinkTimeOptimization.html I have no problems with > 64-bit compilation, but get

I tried compiling a simple source file "int main(){return 0;}" with clang -O4 -m32 -use-gold-plugin and I get the following error:ld: error: /tmp/llvmgold.o: incompatible targetld: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/crt1.o:(.text+0x18): error: undefined reference to 'main' I have no issues compiling it without -m32. Is there a way to fix this?Thanks

Luke Dalessandro wrote: > OK. So I've discovered --with-sysroot which seems to be grabbing and > patching the include files correctly. Now it's dieing with > > ./options.h:462: error: 'HOST_BITS_PER_INT' undeclared here (not in a > function) > ./options.h:462: error: bit-field 'padding' width not an integer constant > > which appears to be

Thanks for providing me with those examples. My rather inefficient pass, which inherits from ModulePass, currently iterates through the Module, Functions, and BasicBlocks multiple times (once to find strcpy, another to find strcat, and so on for various other functions). If I only care about the direct calls, would I benefit more from switching to multiple use_iterators or the InstVisitor

Mike Stump wrote: > On Oct 31, 2008, at 1:10 PM, Luke Dalessandro wrote: >> I've started trying by trying to get sparc-sun-solaris2.10 (niagara) >> working. It appears that neither llvm nor llvm-gcc will build natively >> on the system, so I think that I need to build an llvm-gcc cross >> compiler. > > Get a gcc binary from someplace, use that to then build

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

Gents, I am trying to do a "gcc -m32" on a x86_64 box. gcc -m32 /tmp/jj.c /usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status This is the error I get. I did a "yum install glib.i386" successfully. there is no "yum install glib-devel.i386". How can i get a "gcc -m32" compile on my x86_64? THanks, Jerry

Hi all, after reading and learning much more about GNU's configure and compile machine than I ever wanted ;-), I arrived at configuring llvm-2.2 like this: CFLAGS=-m32 CXXFLAGS=-m32 ./configure --prefix=$HOME The assembler errors are finally gone (phew!, and thanks for all the help!), but I get linker errors now: llvm[3]: Linking Release Object Library LLVMX86.o llvm[3]: Compiling

Hi, I’m using _mm_storel_epi64/ _mm_loadl_epi64 in my test case as below and generating 32-bit code (using -m32 and -msse4.2). The 64-bit load and 64-bit store operations are replaced with two 32-bit mov instructions, presumably due to the use of uint64_t type. If I use __m128i instead of uint64_t everywhere, then the read and write happen as 64-bit operations using the xmm registers as expected.

On Apr 14, 2009, at 1:49 PM, Luke Dalessandro wrote: > > On Apr 14, 2009, at 12:48 PM, Brice Lin wrote: > >> I just read the LLVM Programmer's Manual, which mentions (but >> specifically does not include any details of) the InstVisitor >> template. Could someone please provide an example of how to use this >> template to find (as an example) all CallSites for

Hi Russell, I took care of these points except for > In -version output, > > Low Level Virtual Machine (http://llvm.org/): > llvm version 2.6svn > Optimized build. > Built Feb 14 2010(11:05:20). > > Registered Targets: > alpha - Alpha [experimental] > arm - ARM > bfin - Analog Devices Blackfin [experimental] > c - C

Pre-empting Chris's inevitable response: don't add intrinsics! I really like the 'disappearing function calls' idea. Chris suggested practically the same thing for a previous question about adding BigInt support. Anthony, whichever route you take in the end, please consider documenting your 'code adventure' on the wiki so others can learn from your experience. Justing

In -help output, -help - Display available options (--help-hidden for more) Both single and double - option markers are accepted, which is good. It would probably be better to refer to options consistently using the single marker in all cases. =linearscan - linear scan register allocator =pbqp - PBQP

I am trying to do some research that involves instrumenting LLVM IR, that I need to test for performance and scalability on a bunch of systems. I've started trying by trying to get sparc-sun-solaris2.10 (niagara) working. It appears that neither llvm nor llvm-gcc will build natively on the system, so I think that I need to build an llvm-gcc cross compiler. The documentation for building

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

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

Luke Dalessandro wrote: > S. Bharadwaj Yadavalli wrote: >> $ ../../../src/llvm-gcc-4.2/configure >> --prefix=<llvm-root>/install/x86_64-arm/llvm-gcc-4.2 >> --program-prefix=llvm-x86_64-arm >> --enable-llvm=<llvm-root>/install/x86_64-arm/llvm >> --enable-languages=c,c++ --disable-multilib >> --target=arm-unknown-linux-gnueabi > > I

I've been asked how LTO in LLVM compares to equivalent capabilities in GCC. How do the two compare in terms of scalability? And robustness for large applications? Also, are there any ongoing efforts or plans to improve LTO in LLVM in the near future? Any information would be much appreciated. Thanks, --Vikram S. Adve Visiting Professor, Computer Science, EPFL Professor, Department of

Thanks for the quick responses. "disappearing function calls" is by far the preferred way for me, as I want my pass to work with standard LLVM and not a hacked version that supports extra pragmas, or intrinsics. I am just new to LLVM and wanted to make sure that there isn't already a mechanism for passing meta-data between the user and the optimizer. I am planning to

*I am sorry for making you confused when I presented my problem.* *1. My steps for the test suit building:* (1) cd /home/qali/Src; * // This is my source directory for all application programs* (2) tar xzf llvm-2.8.tgz; * // now, the top directory of source tree is /home/qali/llvm-2.8* (3) cd llvm-2.8/projects (4) svn co http://llvm.org/svn/llvm-project/test-suite/trunk