similar to: [LLVMdev] how often doInitialization in Looppass is called?

Hi Chandler, On 17/12/12 13:47, Chandler Carruth wrote: > On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > > I'm wondering if the documentation for LoopPass >

On Sun, Dec 16, 2012 at 7:23 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Stephen, > > > On 13/12/12 18:58, Stephen McGruer wrote: > >> I'm wondering if the documentation for LoopPass >> (http://llvm.org/docs/**WritingAnLLVMPass.html#**LoopPass<http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass>) >> is misleading or >> incorrect (or

Hi Stephen, On 13/12/12 18:58, Stephen McGruer wrote: > I'm wondering if the documentation for LoopPass > (http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or > incorrect (or if I'm just missing something.) The documentation states: > > "The doFinalization method ... is called when the pass framework has finished > calling runOnLoop

I'm wondering if the documentation for LoopPass ( http://llvm.org/docs/WritingAnLLVMPass.html#LoopPass) is misleading or incorrect (or if I'm just missing something.) The documentation states: "The doFinalization method ... is called when the pass framework has finished calling runOnLoop<http://llvm.org/docs/WritingAnLLVMPass.html#runOnLoop> for every loop in the program being

I'd just note that not every pass you can run with "opt" is actually part of the optimization pipeline. There are a few important IR-level passes that only run in the codegen pipeline, but are still nameable with opt to run individually for testing purposes. Switching over doesn't need to block on these passes being migrated. So I'm not sure this method of determining

-Yuanfang > -----Original Message----- > From: Arthur Eubanks <aeubanks at google.com> > Sent: Monday, July 13, 2020 12:49 PM > To: Chen, Yuanfang <Yuanfang.Chen at sony.com> > Cc: LLVM Developers' List <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by > new pass manager > > While we're

On Aug 19, 2008, at 12:32 PM, David Greene wrote: > Are LoopPasses allowed to maintain state between runOnLoop > invocations? What kind of information are you looking to maintain between runOnLoop invocations ? > > The documentation is not clear on this point. doInitialization() and doFinalization() will be run for each pass before and after runOnLoop(). For each pass

On Tuesday 19 August 2008 15:15, Devang Patel wrote: > On Aug 19, 2008, at 12:32 PM, David Greene wrote: > > Are LoopPasses allowed to maintain state between runOnLoop > > invocations? > > What kind of information are you looking to maintain between runOnLoop > invocations ? Cached analysis answers. > > The documentation is not clear on this point. > >

Hello guys, Do we have a pass to do unconditional branch folding except the one in Codegen? I checked in the lib/Transforms/Scalar, did not see any promising one. thank you, yuanfang

On Mon, Dec 17, 2012 at 4:57 AM, Duncan Sands <baldrick at free.fr> wrote: > would it still be possible to optimize and codegen functions as they are > output > (rather than waiting for the module to be completely output before doing > this)? > I would assume so... What gives you pause here? (TBH, I've not really thought about this deeply, so I may be missing something

Are LoopPasses allowed to maintain state between runOnLoop invocations? The documentation is not clear on this point. -Dave

Hello folks, I wrote a transforming looppass for my project, opt --help can see it. I want clang to use my pass too, so that I don't have to compile to IR, opt, and then llc to binary manually. Now I am trying to add my pass to O2 by mimicking LICM pass. I add a line "MPM.add(createMyPass());" in PassManagerBuilder::populateModulePassManager, and got assertion fail "void

Basically I have two separate passes (first is a loop pass) which are two different files and two different opts but I need to keep the data consistent (ie, I want the changes to show up the resulting .bc output file from the first (loop) pass so the second pass can use these new names. Currently, when I print out "BB->getName().str()" after the code below, I get the correct renaming

Hello guys, For single scalar pointer parameter, we have 'byval' to specify the pointee is not changed. But for base+range parameters like: declare void @_gfortran_transfer_integer_write(%struct.__st_parameter_dt*, i8*, i32) (This is the fortran runtime api to 'printf' one integer) The 2nd & 3rd args are used to specify the memory of that integer. I didn't find a

Hi Tim, > From: Tim Creech <tcreech at umd.edu> > Subject: [LLVMdev] IVUsers (LoopPass) analysis in a ModulePass? > Date: September 1, 2011 11:46:28 AM PDT > To: llvmdev at cs.uiuc.edu > > Hi all, > I have a loadable ModulePass which does transformations, and I would like to > use IVUsers analysis within it. I noticed when I try to do this (via > the usual

Hi Edvard, _ZTIN4llvm8LoopPassE is "typeinfo for llvm::LoopPass". LLVM is built without typeinfo, so you will need to build your pass with -fno-rtti. Ciao, Duncan. > I'm trying to implement LoopPass. > Here is simple code : > > class LoopParser: public llvm::LoopPass > { > public: > static char ID; > > public: > virtual

One thing I want to mention. I believe in the current legacy pass manager implementation only one MachineFunction ever exists at a time. It is deleted before the next MachineFunction is created. This is very important for memory usage. I think the MachineOutliner being in the pipeline may create an exception to this. I think the initial version of retpoline used a ModulePass and that had to be

Hello . I'm trying to implement LoopPass. Here is simple code :    class LoopParser: public llvm::LoopPass   {     public:       static char ID;     public:       virtual void getAnalysisUsage(llvm::AnalysisUsage &AU) const       {         AU.addRequiredID(llvm::LoopSimplifyID);         AU.addPreservedID(llvm::LoopSimplifyID);         AU.addRequired<llvm::LoopInfo>();       }    

LLVMers, So, I'm trying to write a pass that changes the names of the basic blocks through the use of Value, so: Value *V = *BasicBlockPtr; const Twine Tname("new_name"); V->setName(Tname); But when I run the opt and look at the IR output nothing is changed? Not sure what I'm doing wrong. Thanks. -------------- next part -------------- An HTML attachment was

On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Indeed, but there is a distinction about their position in the pipeline. We run opt & codegen pipeline separately, Why, though? Is there a reason why this inherently makes sense, or is it just a historical accident? At least to me it seems that it would make more sense to run all passes