similar to: [LLVMdev] BYTECODE_LIBRARY warning

Hi Ahmad, If the Makefile contains only this command, then it is not worth spending time on GoldPlugin. If you are building a large project, then it will be simpler to use GoldPlugin. The steps you are using seem right. You can possibly combine the last two steps (3&4) using only 1 clang command. clang -g -O2 -o .libs/mergedexe .libs/mergedbc.bc -pthread -Wl,--export-dynamic

"Hassan, Ahmad" <ahmad.hassan at sap.com> writes: > I would like to ask if LLVM provides a utility function like > 'isMallocCall' to check if the 'call' instruction is calling some > 'foo' user defined function? > > If there is no such utility function then I am thinking to do this in > the following way: > > bool testFoo(CallInst

Hi Ahmad, Yes, merging works good. However, my problem is like this - I have a C library which consists of 1000's of functions spread through various files. The functions do not have dependency amoung each other. I want to link only relavant files( files which have functions called from my application). Since ar has a global symbol table, I believe it should be faster to look for a symol in

Just to keep others in loop. This issue has been fixed by following additions in Makefile: CPP.Flags += -U_FORTIFY_SOURCE CPP.Flags += -D_FORTIFY_SOURCE=0 Thanks, Ahmad From: ahmad.hassan at sap.com Sent: 07 January 2013 19:52 To: llvmdev at cs.uiuc.edu Subject: _FORTIFY_SOURCE warnings Hi All, I have modified the Makefile inside llvm/tools/clang and added the following flag: CPP.Flags +=

Hi, I would like to ask if LLVM provides a utility function like 'isMallocCall' to check if the 'call' instruction is calling some 'foo' user defined function? If there is no such utility function then I am thinking to do this in the following way: bool testFoo(CallInst *CI) { Function *Callee = CI->getCalledFunction(); if (Callee->getName() == "foo")

Hi Duncan, > 4.gcc -g -O2 -o .libs/mergedexe .libs/mergedbc.s -pthread > -Wl,--export-dynamic .libs/lib1.a -lssl -lcrypto -ldl -pthread .libs/lib2.so >if you pass -O4 rather than -O2 to clang I think it will in essence do this all >for you already. It might even do the link time optimization for you at -O2 >even, I'm not sure. No, if I use clang for producing

Hi All, I am migrating a build system of an existing project from 'Object files' based executable generation to 'LLVM Bitcode' files based exe generation and applying OPT pass to LLVM Bitcode. I found out the following 4 step procedure. Please let me know if this is the right procedure or is there any other easy way of doing it. I need to modify 'Makefile' accordingly. I

I tried debugging it and the issue seems to be in the implementation of MachineInstrIterator.h and the way it interacts with GraphWriter.h functions. I found this by replacing the ( template <> struct GraphTraits<MCDFGraph<MachineFunction*> >) with a similar MCDFGraph based template of CFG similar to the one in MachineFunction.h (similarly replacing the DOTGraphTraits with the

Hi Ankur, Why do you need archive in this case? The other way of doing this is to merge all bitcode files into single file: $ clang -c -emit-llvm abc.c -o abc.bc $ clang -c -emit-llvm bcd.c -o bcd.bc llvm-link bcd.bc abc.bc -o merged.bc Cheers, Ahmad From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ankur deshwal Sent: 21 February 2013 17:54 To:

Hi, I am trying to generate the DFG of machine functions. Initially, I added a pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h

Some time ago we reported a compile-time performance regression in the LiveIntervals analysis pass (see http://llvm.org/bugs/show_bug.cgi?id=18580). We detected it at first after migrating from LLVM 3.1 to 3.3, but the problem persists also in 3.5. This regression is especially critical when compiling long functions. In one of our benchmarks compile time goes from 200s (in 3.1) up to 1500s (in

Hi Ahmad, On 03/01/13 16:26, Hassan, Ahmad wrote: > Hi Team, > > I am migrating one of the Pass that was written for llvm2.2 or older to llvm3.1. > The code snippet looks like the following: > > Constant *func; > > void add( Module *M) { > > func = M->getOrInsertFunction("func", Type::getVoidTy(M->getContext()), NULL); this function has no

Hi Ahmad, On 17/01/13 14:56, Hassan, Ahmad wrote: > Hi All, > > I am migrating a build system of an existing project from ‘Object files’ based > executable generation to ‘LLVM Bitcode’ files based exe generation and applying > OPT pass to LLVM Bitcode. I found out the following 4 step procedure. Please let > me know if this is the right procedure or is there any other easy way

Hi Team, I am migrating one of the Pass that was written for llvm2.2 or older to llvm3.1. The code snippet looks like the following: Constant *func; void add( Module *M) { func = M->getOrInsertFunction("func", Type::getVoidTy(M->getContext()), NULL); } virtual bool runOnModule(Module &M) { add (&M); for(Module::iterator F = M.begin(), E = M.end(); F !=

Hi, I tried to build an llvm archive and link it against an llvm bc file. However, it fails. Following is the procedure I followed ( abc.c is file which calls a function whose definition is present in bcd.c) $ clang -c -emit-llvm abc.c $ clang -c -emit-llvm bcd.c $ llvm-ar cr bsd.ar bcd.o $ llvm-link abc.o bsd.ar llvm-link: bsd.ar:1:2: error: expected integer !<arch> ^ llvm-link:

On Wed, 2004-12-22 at 22:38, Markus F.X.J. Oberhumer wrote: > Hello Reid, > > > > @@ -167,7 +168,7 @@ > > > if test ${enableval} = "no" ; then > > > AC_SUBST(ENABLE_OPTIMIZED,[[]]) > > > else > > > - AC_SUBST(ENABLE_OPTIMIZED,[[ENABLE_OPTIMIZED=1]]) > > > + AC_SUBST(ENABLE_OPTIMIZED,[[1]]) > > > > This is not

>> > > (I'm jumping into the middle of this conversation as it looks like you're discussing something that might be relevant to my work. Sorry I'm not up to speed on the full context of the discussion...) > > If you are asking whether anyone is using machinery in LLVM's build system to compile programs into LLVM bitcode files, the answer is yes. The LLVM

Dear LLVM developers, I am wondering the gcc optimization flag for "ENABLE_OPTIMIZED=1" in LLVM is -O2 or -O3. And what is the flag if I set "ENABLE_OPTIMIZED=0"? If I want to manually modify the flag for "ENABLE_OPTIMIZED=1" in LLVM, what file should I refer to? -- Regards, Heming Cui -------------- next part -------------- An HTML attachment was

So IMO, if we modify the VF calculation for targets/subtargets using TTI where higher VF is supported The vectorizer’s scope will become wider. Did/do you foresee any issue with this? Thanks, Shahid From: Nadav Rotem [mailto:nrotem at apple.com] Sent: Saturday, December 13, 2014 2:47 AM To: Shahid, Asghar-ahmad Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Vectorization factor limitation in

> For the time being, if you can get away with heuristics, and that fills your > allocated time for this task, that it's the best way forward for now. Sorry that I could not get what exactly you mean with "heuristics". Is it the "intrinsics approach" itself or something else? BTW, now my plan is to just add the two intrinsics for 'absolute difference' and