search for: argumentpromot

Hi all, I was looking at the StructRetPromotion pass this morning and noticed it doesn't look at a function's linkage at all. Since it changes the signature of the function, I would say it should only change internal functions, like ArgumentPromotion does for example. Is there some implicit check I'm missing, or should an explicit check really be added? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature U...

Hi Stepan, After discovering several bugs in ArgumentPromotion and DeadArgumentElimination where llvm::Functions were replaced with similar functions (with the same name) to transform their type in some way, I started looking at all calls to llvm::Function::takeName to see if there were any other debug info quality bugs in similar callers. One such caller...

Hi, the ArgumentPromotion pass replaces aggregrate function arguments by multiple individual arguments. The default pass only does this when the aggregrate has 3 or less elements, otherwise the code will be unchanged. I have a need to always promote aggregrate arguments, even when there are a lot of them. The attached...

Hi Peter, After discovering several bugs in ArgumentPromotion and DeadArgumentElimination where llvm::Functions were replaced with similar functions (with the same name) to transform their type in some way, I started looking at all calls to llvm::Function::takeName to see if there were any other debug info quality bugs in similar callers. One such caller...

...our mail briefly, > tomorrow I'll provide you with detailed information. By now you could > use tests from  $LLVM/test/Transforms/MergeFunc/ as examples. > > Cheers! > -Stepan > > David Blaikie wrote: >>  Hi Stepan, >> >>  After discovering several bugs in ArgumentPromotion and >>  DeadArgumentElimination where llvm::Functions were replaced with similar >>  functions (with the same name) to transform their type in some way, I >>  started looking at all calls to llvm::Function::takeName to see if there >>  were any other debug info quality bu...

...t;> >> thanks, >> >> David >> >> >> >> >>> Sean:~/pg/llvm % git grep 'public CallGraphSCCPass' >>> include/llvm/Transforms/IPO/InlinerPass.h:struct Inliner : public >>> CallGraphSCCPass { >>> lib/Transforms/IPO/ArgumentPromotion.cpp: struct ArgPromotion : public >>> CallGraphSCCPass { >>> lib/Transforms/IPO/FunctionAttrs.cpp:struct >>> PostOrderFunctionAttrsLegacyPass : public CallGraphSCCPass { >>> lib/Transforms/IPO/PruneEH.cpp: struct PruneEH : public >>> CallGraphSCCPas...

On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: > > Hi Peter, > > > > After discovering several bugs in ArgumentPromotion and > > DeadArgumentElimination where llvm::Functions were replaced with similar > > functions (with the same name) to transform their type in some way, I > > started looking at all calls to llvm::Function::takeName to see if there > > were any other debug info quality bu...

...em out? A problem of that seems to be that it is hard for sretpromotion to simply add return values, since it doesn't know whether to add to the existing struct return type (if any) or create a new struct return type. I guess integrating these two passes makes the most sense, then. I guess the argumentpromotion pass also needs to be adapted to promote first class struct arguments (probably handle them identical to how byval pointer-to-struct are handled now), but I don't currently have need of that. Lastly, I'll modify IPConstProp and DeadArgElim to properly handle multiple return values and d...

...saying here. What do you mean by flattening out nested structs? If you mean moving all the members in nested structs to be members of a single non-nested struct, that doesn't really buy anything, because extractvalue and insertvalue can index directly into nested structs. > > I guess the argumentpromotion pass also needs to be adapted to > promote first > class struct arguments (probably handle them identical to how byval > pointer-to-struct are handled now), but I don't currently have need > of that. > > Lastly, I'll modify IPConstProp and DeadArgElim to properly ha...

...t; >> >> On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: >>> > Hi Peter, >>> > >>> > After discovering several bugs in ArgumentPromotion and >>> > DeadArgumentElimination where llvm::Functions were replaced with >>> similar >>> > functions (with the same name) to transform their type in some way, I >>> > started looking at all calls to llvm::Function::takeName to see if >>> th...

Hi all, I am a newbie and have a question. Using llvm, I want to change the original function into a new function which have an additional pointer argument: original function: int haha(int n) { .... } new function: int haha(int n, *ptr) { ... } Could you give me a suggestion? Thank you in advance. Shawn -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi all, Currently in the llvm middle-end, we disable some optimizations because we worry about the register pressure, (e.g. GVNHoist and ArgumentPromotion). However, in the architecture that are register-rich, e.g. FPGAs, we do not need to worry about the register pressure at all. For these architecures, we may want to optimization the LLVM IR without worrying about the register pressure. I suggest that we introduce a hook in the TargetTransform...

Hi Everyone, Can Someone tell me all the interprocedural optimizations that LLVM 2.1 supports. Thank You, Naineet Patel CSE IITB

Hi All, in the last few days I've been working on a fix for PR2498. Currently ArgumentPromotion is a bit overzealous when promoting arguments: If any load of a pointer argument happens in the entry block (even a partial load for a struct pointer), it assumes that all loads in the function can be promoted to the caller (and thus executed uncondtionally). This is clearly wrong, as PR2498 ill...

...is information is available in the comments at the top of the file for the optimization). This has been on my TODO list for about 2.5 years now, but I have a *very* long TODO list. :) Here are some examples of the header comments: http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/lib/Transforms/IPO/ArgumentPromotion.cpp?rev=1.5&content-type=text/x-cvsweb-markup http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/lib/Transforms/IPO/DeadArgumentElimination.cpp?rev=1.16&content-type=text/x-cvsweb-markup http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/lib/Transforms/Scalar/LICM.cpp?rev=1.59&content-type=t...

Hi devels, there are two issues concerning invoking optimizations: 1. this document: http://llvm.cs.uiuc.edu/docs/GettingStarted.html is very nice, it would be good though to add in a section An Example Using the LLVM Tool Chain examples on optimization step. 2. If i am not wrong there is no tool, which integrates all steps: llvmgcc->opt->llc into something like llcc (and

...gbourne <peter at pcc.me.uk > > > > >> wrote: > > >> > > >>> On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: > > >>> > Hi Peter, > > >>> > > > >>> > After discovering several bugs in ArgumentPromotion and > > >>> > DeadArgumentElimination where llvm::Functions were replaced with > > >>> similar > > >>> > functions (with the same name) to transform their type in some > way, I > > >>> > started looking at all calls to llvm:...

...2 alloca in the first place. Also, in the code where I originally noticed this problem, the resulting code is more complex and less likely to be simplified again. In particular, instead of the @empty function I have a call to memmove, whose destination is passed as an argument to another function. ArgumentPromotion is able to split up this struct argument and remove the memmove, but by then the alloca is already screwed up by instcombine and scalarrepl is no longer able to properly expand it. Any comments on this problem? Do you agree that the current replacement policy of PromoteCastOfAllocation is a bi...

...>> wrote: > > > > >> > > > > >>> On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: > > > > >>> > Hi Peter, > > > > >>> > > > > > >>> > After discovering several bugs in ArgumentPromotion and > > > > >>> > DeadArgumentElimination where llvm::Functions were replaced > with > > > > >>> similar > > > > >>> > functions (with the same name) to transform their type in some > > > way, I > > > >...

...t return and insertvalue instead?). Since an sret function will, by definition, have a void return type, the new return values will never have to be merged. In that light, I will be probably building an internal (i.e., to our company) pass that flattens struct return values. > > I guess the argumentpromotion pass also needs to be adapted to > > promote first > > class struct arguments (probably handle them identical to how byval > > pointer-to-struct are handled now), but I don't currently have need > > of that. > > > > Lastly, I'll modify IPConstProp...