similar to: [LLVMdev] call graph not complete

Hi, > Bitcode generated by llvm-ld with –disable-opt and –basiccg options is: ... > My point is why is the call to foo not resolved correctly in llvm-ld. Resolving an call to a direct call is an optimization. But you turned all optimizations off. Ciao, Duncan.

Duncan Sands wrote: > Hi, > > >> Bitcode generated by llvm-ld with –disable-opt and –basiccg options is: >> > > ... > > > >> My point is why is the call to foo not resolved correctly in llvm-ld. >> > > Resolving an call to a direct call is an optimization. But you turned all > optimizations off. > > BTW, why do

Duncan Sands wrote: > Hi, > > >> Bitcode generated by llvm-ld with –disable-opt and –basiccg options is: >> > > ... > > > >> My point is why is the call to foo not resolved correctly in llvm-ld. >> > > Resolving an call to a direct call is an optimization. But you turned all > optimizations off. > How can we just

Duncan Sands wrote: > Hi, > > >> Bitcode generated by llvm-ld with –disable-opt and –basiccg options is: >> > > ... > > > >> My point is why is the call to foo not resolved correctly in llvm-ld. >> > > Resolving an call to a direct call is an optimization. But you turned all > optimizations off. > > Ciao, > >

This is what the document says: Module-Level Inline Assembly Modules may contain "module-level inline asm" blocks, which corresponds to the GCC "file scope inline asm" blocks. These blocks are internally concatenated by LLVM and treated as a single unit, but may be separated in the .ll file if desired. The syntax is very simple: module asm "inline asm code goes

Duncan Sands wrote: > Hi Sanjiv, > >> How can we just selectively turn only that optimization ON? > > you can't. That said, you could write your own pass that does it. > >> We don't want to turn on a whole lot of other stuff that instcombine >> does as they mess up debugging in our case. > > If instcombine makes debug info useless, then that's

Thanks to you both. On my Linux (centos6) system, I have reproduce a variant of the bug and learned about -plugin-opt=-debug-pass=Arguments which I infer from comments is intended to built arguments to “opt” however I found that some of the arguments don’t seem to be quite correct. I assume this just minor bit rot. bin/opt -o pass1.bc -datalayout -notti -basictti -x86tti -targetlibinfo

Suppose I have fun.h as: static void fun() { int a =10; } Now I have two files foo.c and goo.c as foo.c : #include "fun.h" void foo() { fun(); } goo.c: #include "fun.h" void goo() { fun(); } I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld with -disable-opt for foo.bc and goo.bc. In the resulting .bc files, one of the

On Mon, Jun 8, 2009 at 3:25 AM, <Vasudev.Negi at microchip.com> wrote: > > I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld > with -disable-opt for foo.bc and goo.bc. In the resulting .bc files, one > of the two functions fun, is renamed to fun<number>. There are two > llvm.dbg.subprogram descriptors created for the two fun functions. Both > have

Hi Sanjiv, > How can we just selectively turn only that optimization ON? you can't. That said, you could write your own pass that does it. > We don't want to turn on a whole lot of other stuff that instcombine > does as they mess up debugging in our case. If instcombine makes debug info useless, then that's rather bad. Can you please explain more about this. Ciao,

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but

Hi, I want to write a piece of code to instrument c++ programs. I have finished writing the pass, but I do not know how to get the resultant bitcode I ran OPT with the following arguments: opt -basiccg -basicaa -load /home/andy/llvm-3.0.src/Release/lib/InstTest.so -InstTest </home/andy/llvm-3.0.src/workspace/threadTest/Debug/threadTest.bc> -o=</home/andy/output/out.bc> /dev/null

Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. https://llvm.org/docs/SourceLevelDebugging.html discusses some of the debug info IR metadata in LLVM. On Fri, Feb 2, 2018 at 1:03 AM Ku Nanashi via llvm-dev < llvm-dev at lists.llvm.org> wrote:

> Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. Thank you for the comment! I don't know if this is a proper way to fix, but after I add DebugLoc same as inserting position instruction, no error occurs.

Hello, I am trying to simplify the CFG of a given code and eliminate the conditionals, even though I will obtain codes that are not semantically equivalent. For example, given a simple loop: for(i=0; i<N; i++){    a[i] = i;     if (i%2==0)       a[i] += 12; } I would keep only the loop, without the if statement: for(i=0; i<N; i++){    a[i] = i; } I can eliminate such conditionals on

Hi, List, As you may know, BCC of android makes use of LLVM's major components. Its LTO actually selects some optimizations of LLVM. I found it can not only use "-functionattrs". I must first use -argpromotion first, or I end up this error: Pass 'Deduce function attributes' is not initialized. Verify if there is a pass dependency cycle. Required Passes: bcc:

On 2009-05-10 21:18, Nick Johnson wrote: > On 5/10/09, Török Edwin <edwintorok at gmail.com> wrote: > >> On 2009-05-10 20:11, Nick Johnson wrote: >> > Hello, >> > >> > I'm writing a Function Pass. This function pass needs access to the >> > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph >> >

On 5/10/09, Török Edwin <edwintorok at gmail.com> wrote: > On 2009-05-10 20:11, Nick Johnson wrote: > > Hello, > > > > I'm writing a Function Pass. This function pass needs access to the > > CallGraph and CallGraph SCCs. Is there any way I can get CallGraph > > information without changing my pass to a CallGraphSCCPass ? > > > Does

to compile it to bitcode I give the following command : llvm-gcc -emit-llvm -c -o s.bc s.c and then I run different alias analysis passes like -anders-aa, -basicaa using following: opt -anders-aa -aa-eval -print-all-alias-modref-info s.bc From this I get the following output: Function: main: 8 pointers, 1 call sites NoAlias: i32* %retval, i32** %j NoAlias: i32* %retval, i32**

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias