search for: constmerge

...erested in telling the compiler not to inline a given function, and discovered that the __attribute__((noinline)) implements this using a global variable @llvm.noinline. It did not work for me initially. I noticed that @ llvm.noinline was being internalized by -internalize, dead-code-eliminated by -constmerge, causing this information not to reach the -inline pass. I am not sure if this is a bug, or I am just using the passes in some wrong way. Initially I thought, maybe I was being a clown by doing "opt -internalize -constmerge -inline" in that order, but then I discovered that even llvm-ld...

Hi, On Sat, Sep 5, 2009 at 9:12 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > Is the patch below ok? > > Index: LLVMCConfigurationEmitter.cpp > =================================================================== > --- LLVMCConfigurationEmitter.cpp    (revision 80668) > +++ LLVMCConfigurationEmitter.cpp    (working copy) > @@ -1141,6 +1141,7 @@ >          

I wrote a pass that attempts to add up the total size of the global data in a module. Currently, it iterates through all of the global values and checks their type sizes using TargetData. I have realized that this is not quite right because global values can point to the same data in memory (or can at least overlap) as in the case of constant strings. Is there an easier way to approach this? It

...data in memory (or can at least overlap) as in the case of > constant strings. It's impossible to tell what exactly will get merged until link-time; also, CodeGen often introduces constant globals. That said, as far as I know, LLVM doesn't know how to merge constants beyond running the constmerge pass and emitting globals into sections which can be merged. What are you actually trying to do? -Eli

...better luck. Not marking the variable const only makes the problem more obscure. Testcase in C: static char x = 1, y = 1;int c() {char* u = &x; char* v = &y; return u == v;} int d() {return x+y;} Running this through "llvm-gcc -O0 -emit-llvm -c -x c - -o - | opt -mem2reg -globalopt -constmerge -instcombine" has precisely the same effect: c returns 1. It's conceivable that globalopt+constmerge could do even crazier stuff. Potential example: suppose we have two mallocs, and store the allocated pointers into globals. GlobalOpt knows how to turn mallocs into statically allocated...

...why do not let people verify each pass in -O{1,2,3} pipeline? My second question is more about debugify: what should be the best way to debugify each pass? Adding a debugify-each mode would make the output unreadable! Maybe writing a script that collects all optimization options (like -mem2reg or -constmerge), then pass each one of them to opt with -enable-debugify so that we have 1 output file for each debugified pass? Thank you for your help, Son Tuan Vu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180314/...

...ing all of pymol 1.1r2 with > -O4 on darwin9. Everythink links and there appears to be > no regressions in the resulting code. I take it that LTO > in llvm 2.5 is still limited to dead code elimination, > correct? No. libLTO does the equivalent to opt -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine -inline -prune-eh -globaldce -argpromotion -instcombine -jump-threading -scalarrepl -globalsmodref-aa -licm -gvn -memcpyopt -dse -instcombine -jump-threading -mem2reg -simplifycfg -globaldce Will LTO ever be extended to inlining across > files as well as constant-...

Which transformation passes are 'safe', meaning it does not worsens the effectiveness of a later pass or the generated code? I imagine all passes which either removes data or add attributes are included in this list, plus some simplification passes: -adce -argpromotion -constmerge -constprop -deadargelim -dse -functionattrs -globaldce -globalopt -gvn -instcombine -internalize -ipconstprop -ipsccp -licm -prune-eh -sccp Also, is there any redundant pass in this list (things line sccp/ipsccp)?

...e, lets say we have %Foo = type { i32 } %Bar = type { i32 } @a = unnamed_addr constant %Foo { i32 42 } @a = unnamed_addr constant %Bar { i32 42 } The typemerge pass could turn this into @a = unnamed_addr constant {i32} { i32 42 } @b = unnamed_addr constant {i32} { i32 42 } And constmerge will then merge them as it does today. Another comment is that getting anonymous types would still be a bit expensive. Can we get away with just Named types (including Unnamed) and trusting typemerge to do its job? > -Chris Cheers, Rafael

I've had better luck compiling all of pymol 1.1r2 with -O4 on darwin9. Everythink links and there appears to be no regressions in the resulting code. I take it that LTO in llvm 2.5 is still limited to dead code elimination, correct? Will LTO ever be extended to inlining across files as well as constant-folding and global data allocation optimizations? Or does the reliance on gcc-4.2 as the

On Sat, 19 May 2007, Anton Korobeynikov wrote: >> * It seems that a C-call like printf("---\n") is transformed to puts >> ("---") in the LLVM IR instead of keeping it a printf. What are the >> circumstances in which this happens? Do other similar conversions >> occur? Can this be turned off (lower optimisation level?)? Manually >> replacing the

...lify -lcssa -iv-users -indvars -loop-idiom -loop-deletion -loop-unroll -instcombine -memdep -gvn -memdep -memcpyopt -sccp -instcombine -lazy-value-info -jump-threading -correlated-propagation -domtree -memdep -dse -adce -simplifycfg -strip-dead-prototypes -print-used-types -deadtypeelim -globaldce -constmerge -globalopt -ipsccp -deadargelim -instcombine -simplifycfg -basiccg -prune-eh -inline -functionattrs -scalarrepl-ssa -domtree -early-cse -simplify-libcalls -lazy-value-info -jump-threading -correlated-propagation -simplifycfg -instcombine -tailcallelim -simplifycfg -reassociate -domtree -loops -loop...

...-instcombine -scalar-evolution -loop-simplify -lcssa -indvars -loop-idiom -loop-deletion -loop-unroll -memdep -gvn -memdep -memcpyopt -sccp -instcombine -lazy-value-info -jump-threading -correlated-propagation -domtree -memdep -dse -adce -simplifycfg -instcombine -strip-dead-prototypes -globaldce -constmerge -preverify -domtree -verify file.ll However, I am not successful in calling the passes in this form, as I already get an error on the first pass: LLVM ERROR: Bad TargetData ctor used.  Tool did not specify a TargetData to use? Any advice on how can I either: (i) disable loop rotation (ii) inhibit...

On Oct 15, 2008, at 6:58 AM, Tatu Vaajalahti wrote: >> Yes, but why do you think they should get a different address? I can >> understand that it is surprising that they do, but determining >> whether >> this is legal or not requires reading the language standard. >> Hopefully >> a language lawyer can chime in and say whether this transform is >>

...a -branch-prob -block-freq -scalar-evolution -loop-vectorize > -instcombine -scalar-evolution -slp-vectorizer -simplifycfg -domtree > -instcombine -loops -loop-simplify -lcssa -scalar-evolution -function_tti > -loop-unroll -alignment-from-assumptions -strip-dead-prototypes -globaldce > -constmerge -playdep -verify -verify-di -print-module > Target Library Information > Data Layout > No target information > Target independent code generator's TTI > X86 Target Transform Info > No Alias Analysis (always returns 'may' alias) > Type-Based Alias Analysis > Scope...

On Tue, 22 May 2007 23:52:46 -0700 (PDT) Chris Lattner <sabre at nondot.org> wrote: >On Sun, 20 May 2007, Bram Adams wrote: >> On a related note: while using llvmc I have some test cases where the >> following error now pops up on Linux X86 (not on OSX): >> >> <premain>: CommandLine Error: Argument 'debug' defined more than once! >> llvmc:

Hello, Bram > * It seems that a C-call like printf("---\n") is transformed to puts > ("---") in the LLVM IR instead of keeping it a printf. What are the > circumstances in which this happens? Do other similar conversions > occur? Can this be turned off (lower optimisation level?)? Manually > replacing the puts-calls by a printf-call is not

...-loop-simplify -lcssa -branch-prob -block-freq -scalar-evolution -loop-vectorize -instcombine -scalar-evolution -slp-vectorizer -simplifycfg -domtree -instcombine -loops -loop-simplify -lcssa -scalar-evolution -function_tti -loop-unroll -alignment-from-assumptions -strip-dead-prototypes -globaldce -constmerge -domtree -loops -loop-simplify -lcssa -licm Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -jump-instr-table-info -targetpassconfig -no-aa -tbaa -scoped-noalias -assumption-tracker -basicaa -collector-metadata -machinemoduleinfo -machine-branch-prob -jump-instr-tables -atomic-...

On 15.10.2008, at 16.43, Duncan Sands wrote: >> True, but note that it is the address of a variable that is used, not >> the value. > > Yes, but why do you think they should get a different address? I can > understand that it is surprising that they do, but determining whether > this is legal or not requires reading the language standard. > Hopefully > a language

...t it seems reasonable. The more conservative definition of the semantics is just to say that the compiler chooses whether any pair of mergeable globals are distinct objects, which is roughly how the current C99 standard defines string merging. This has the following effects on current optimizers: constmerge only merges globals marked mergeable. Only mergeable constants are emitted into mergeable sections in assembly. If we use the conservative definition of mergeable, fix any code that assumes distinct globals don't get merged, like the code that folds equality comparisons between distinct globa...