search for: functionattr

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: external/llvm/lib/VMCore/PassManager.cpp:616: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*...

Hey all, I'm working on adding interprocedural FunctionAttrs optimization ( http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO so it does something similar to what LTO is doing ( https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how the FunctionAttrs optimization expects linkage types. In ThinLTO since the lin...

Hi Charles, On Tue, Jul 11, 2017 at 12:27 PM, Davide Italiano <davide at freebsd.org> wrote: >> I'm working on adding interprocedural FunctionAttrs optimization >> (http://llvm-cs.pcc.me.uk/lib/Transforms/IPO/FunctionAttrs.cpp) to ThinLTO >> so it does something similar to what LTO is doing >> (https://bugs.llvm.org/show_bug.cgi?id=33648). I've hit a problem with how >> the FunctionAttrs optimization expects linkag...

Nick Lewycky wrote: > I was sure that I remember "opt -functionattrs" being taught to do this, > but I just tried it out and it doesn't. This is a missed optz'n > opportunity, testcase: > > @x = constant i32 0 > define void @foo() { > load i32* @x > ret void > } > > is only marked readonly when it s...

The LLVMAddFunctionAttr and LLVMRemoveFunctionAttr are busted: they actually set the return value's attributes, not the function's attributes. There seems to be no C API for actually setting the function attributes. LLVMGetFunctionAttr, however, does correctly return the function attributes, not the retur...

Thanks for the answer Nick. Now you got me on a chase through FunctionAttrs.cpp trying to find out what analysis passes "... which answers no to everything", means. :-) Garrison On Sep 10, 2011, at 13:52, Nick Lewycky wrote: > Nick Lewycky wrote: >> I was sure that I remember "opt -functionattrs" being taught to do this, >> but I just...

...ith ``` define void @infloop(i1 %c) { entry: br i1 %c, label %l, label %e l: br label %l e: ret void } define void @main_func() { entry: call void @infloop(i1 1) ret void } ``` In this program `@main_func`, when called, will loop infinitely. If we run this program through `opt -functionattrs -prune-eh -early-cse`, we get ``` ; Function Attrs: nounwind readnone define void @infloop(i1 %c) #0 { entry: br i1 %c, label %l, label %e l: ; preds = %l, %entry br label %l e: ; preds = %entry...

...he source code 'test.c' is listed as follow: > [...] > The whole process: > > llvm-gcc -emit-llvm -O0 -c test.c -o test.bc > > opt test.bc -load libLLVMDataStructure.so -basic-aa -ds-aa -anders-aa > -aa-eval -print-all-alias-modref-info > Try this: opt -mem2reg -functionattrs -basic-aa -aa-eval -print-all-alias-modref-info test.bc It shows: NoAlias: %struct.Location* %0, %struct.Location* %1 > %1 and %2 are considered as MayAlias results that while using > llvm::MemoryDependenceAnalysis, %2 is dependent on %1(clobber). But in > fact it's not. >...

...(1) there is interest in having better attribute deduction, and (2) there are volunteers to review such patches. I do appreciate any input on this proposal. Cheers, Johannes -------- * It derives function attributes but also parameter and argument attributes. ** lib/Transforms/IPO/FunctionAttrs.cpp *** This statement is intended to sound harsh. I believe it to be appropriate because it is hard to find consistency in the current implementation. Different parts perform argument deduction similarly but still different. This does lead to code duplication and missed deduction...

On Sat, Jun 27, 2015 at 2:46 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > In C, dunno, but in LLVM, it means they aren't readonly :) In that case, -functionattrs needs to be fixed: define void @infloop() { entry: br label %l l: br label %l } == opt -functionattrs ==> ; Function Attrs: readnone define void @infloop() #0 { entry: br label %l l: ; preds = %l, %entry br label %l } attributes #0...

Hi, all According to the document "LLVM Alias Analysis Infrastructure", I evaluated the AA performance by using the paramenters '-basicaa -ds-aa -anders-aa'. The source code 'test.c' is listed as follow: //------------=== Source code ===------------// #include<stdlib.h> typedef struct { int x; int y; } Location; Location* getNewLocation(int x, int y) {

Hello all, During the compilation process, LLVM automatically derives various attributes about functions and values (for example that a pointer is nonnull, a function is constant, etc) that are used within a translation unit. I propose adding a pass to LLVM that allows front-ends to output derived attributes. Such a pass would be useful both for developers and end users to debug programs,

...e duplicating only a few call instructions. It can help EarlyCSE do things that require GVN today: void foo() { ... complex computation that computes func() ... complex computation that computes func() } outlining=> int func() { ... } void foo() { int x = func(); int y = func(); } functionattrs=> int func() readonly { ... } void foo(int a, int b) { int x = func(); int y = func(); } earlycse=> int func(int t) readnone { ... } void foo(int a, int b) { int x = func(a); int y = x; } GVN will catch this, but EarlyCSE is (at least supposed to be!) cheaper. Once we have an...

Hi, Thanks for your advice. I have tried this way: opt -mem2reg test.bc -o mem2reg.bc llvm-dis mem2reg.bc opt -functionattrs -basicaa -aa-eval -print-all-alias-modref-info mem2reg.bc The content of main() in mem2reg.ll: define i32 @main() nounwind { entry: %"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0] %0 = call %struct.Location* @getNewLocation(i32 0, i32 0) nounwind ; < %struct.Loc...

...ograms are translated into LLVM IR using -O0 + -scalarrepl. 2) Find an optimization sequence using some strategy which translates the IR generated in the previous step into another IR. 3) Apply llc -O2 and map the IR in to target assembly code. Using the above setup I found that the sequence [-functionattrs, -loop-rotate, -licm, -basicaa] reduces the runtime of the program from 3.1 seconds (when compiled using -O2) down to 0.1 seconds. Removing any of the optimizations in the sequence including the analysis phase -basicaa increases the runtime back to 3.1 seconds or above. When I was explaining this...

...nite loop and functions which also >> infinite loop but we can't tell will both be considered to have side-effects. >> >> Ciao, Duncan. >> >>> >>> rdar://13227456 >>> >>> >>> Added: >>> llvm/trunk/test/Transforms/FunctionAttrs/noreturn.ll >>> Modified: >>> llvm/trunk/include/llvm/IR/Instruction.h >>> llvm/trunk/lib/IR/Instruction.cpp >>> >>> Modified: llvm/trunk/include/llvm/IR/Instruction.h >>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/ll...

...he subsequent function passes) process a > function, which is bad. I think the pass manager should be fixed to not do > this, at which point the function attributes pass could be moved later. I am not sure I understand this. Here is what I am seeing when I run 'opt -inline -instcombine -functionattrs' Target Data Layout No Alias Analysis (always returns 'may' alias) ModulePass Manager Basic CallGraph Construction Call Graph SCC Pass Manager Function Integration/Inlining FunctionPass Manager Combine redundant instructions Basic CallGraph Constructi...

...e have the new pass manager. On the other hand, maybe we don't need to wait for that now. We now also have a scheme for tagging loops with metadata, and we could use that to add metadata to loops known to have a finite trip count, and then use that metadata in a pass that infers the attribute (FunctionAttrs presumably). -Hal > Maybe Nick remembers more about the issue and why the patch was > dropped. > > Sanjoy: do you have a practical concern about this issue? I mean, of > course > this can be "fixed", but it will require some work, and even a > termination > c...

If a function accesses a global constant array of constants--in my case a constant array of function pointers, and does NOT reference this array via a function argument (it instead directly references this global), is this enough to disallow the application of the readnone attribute to the function in question? Thanks in advance Garrison

...he readnone attribute to the > function in question? A function is readnone if it doesn't access any mutable state, so reading a constant global is fine. (Incidentally, it may even contain stores to constants because any such operation is undefined.) I was sure that I remember "opt -functionattrs" being taught to do this, but I just tried it out and it doesn't. This is a missed optz'n opportunity, testcase: @x = constant i32 0 define void @foo() { load i32* @x ret void } is only marked readonly when it should be readnone. Could I interest you in fixing...