search for: codegenprepar

Hi, I am working on a patch for CodeGenPrepare, which introduces a use of TargetLoweringBase::InstructionOpcodeToISD (see [1] for the details). This is usual for CodeGenPrepare to use the TargetLowering class when it is available, however, using this particular function creates linking problems. ** Context ** The TargetLowering class is part...

Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if a...

...n't CGP, ...) On Fri, Jun 29, 2018 at 12:21 PM Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 6/28/2018 9:44 PM, Bharathi Seshadri via llvm-dev wrote: > > Hi, > > > > I have come across a couple of cases where the code generated after > > CodeGenPrepare pass has "br i1 false .." with both true and false > > conditions preserved and this propagates further and remains the same > > in the final assembly code/executable. > > > > In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which > > handles the br...

...ction selector and scheduler to preserve > Value*'s. the values are attached to machine instructions as a separate > operand list (at least for now). for now this looks very good. Cool! > but i found that the alias analysis is not as good as expected. the > problem seems to be the codegenprepare pass. GEP instructions are > lowered to integer calculations (e.g. ptrtoint, add, inttoptr). this > causes the (basic) alias analysis to answer MayAlias for most queries. > > this is also a problem for the DAG combiner, when the > -combiner-global-alias-analysis switch is given to...

...+ Z] * d->data[j * 3 + Z]; } } } I'm looking through the IR transformations during passes added by LLVMTargetMachine::addPassesToEmitFile and seeing something I could use some help explaining. The point of interest is between 'unreachableblockelim' and 'codegenprepare' passes. Here is the paste of IR after each pass http://pastebin.com/42xLT4ZN I've annotated 3 spots in the code with stars. In (1), after unreachableblockelim, addr89 is precomputed outside the loop once and is used in store in (2). However, in (3), after codegenprepare, there is n...

/Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp: In member function ‘bool<unnamed>::CodeGenPrepare::OptimizeInlineAsmInst (llvm::Instruction*, llvm::CallSite, llvm::DenseMap<llvm::Value*, llvm::Value*, llvm::DenseMapInfo<llvm::Value*>, llvm::DenseMapInfo<llvm::Value*> >&)’: /Volumes/mrs5/net/llvm/llvm/li...

Hi All, In CodeGenPrepare pass, OptimizeMemoryInst() try to sink address computing into users' block by converting GET to integers? It appear that it have impacts on ISel's result, but I'm not clear about the main purpose of the transformation. FROM : for.body.lr.ph: %zzz = getelementptr inb...

I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. Thanks, Jun On Nov 12, 2013, at 12:07 PM, Evan Cheng <evan.cheng at apple.com> wrote: > The reason for this is to allow folding of address co...

The reason for this is to allow folding of address computation into loads and stores. A lot of modern arch, e.g. X86 and arm, have complex addressing mode. Evan Sent from my iPad > On Nov 12, 2013, at 8:39 AM, Junbum Lim <junbums at gmail.com> wrote: > > Hi All, > > In CodeGenPrepare pass, OptimizeMemoryInst() try to sink address computing into users' block by converting GET to integers? It appear that it have impacts on ISel's result, but I'm not clear about the main purpose of the transformation. > > FROM : > for.body.lr.ph: > %zzz...

On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com> wrote: > > I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. I believe it's primary for address mode matching where only part of the GEP can be folded (depending on the instruction set). Evan > > Thank...

I'm looking into some missed optimizations where CodeGenPrepare seems to leave trivially dead instructions lying around. This happens because CodeGenPrepare::runOnFunction calls ConstantFoldTerminator which folds a "br i1 false" into an unconditional branch and calls BasicBlock::removePredecessor which calls PHINode::removeIncomingValue. Each incomi...

----- Original Message ----- > From: "Evan Cheng" <evan.cheng at apple.com> > To: "Junbum Lim" <junbums at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, November 20, 2013 7:01:49 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > > > On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote: > > > > > > > When multiple GEPs or other operations are used for the address > > calculation, OptimizeMemoryInst() performs address matching and > > determines a final...

...ave extended the DAG instruction selector and scheduler to preserve Value*'s. the values are attached to machine instructions as a separate operand list (at least for now). for now this looks very good. but i found that the alias analysis is not as good as expected. the problem seems to be the codegenprepare pass. GEP instructions are lowered to integer calculations (e.g. ptrtoint, add, inttoptr). this causes the (basic) alias analysis to answer MayAlias for most queries. this is also a problem for the DAG combiner, when the -combiner-global-alias-analysis switch is given to llc. any ideas how to ha...

...ssage ----- >> From: "Evan Cheng" <evan.cheng at apple.com> >> To: "Junbum Lim" <junbums at gmail.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, November 20, 2013 7:01:49 PM >> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >> >> >> On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote: >> >>> >>> >>> When multiple GEPs or other operations are used for the address >>> calculation, OptimizeMemoryInst() performs address matching and &...

...only from a single GEP. > > Thanks, > Jun > > > On Nov 12, 2013, at 7:14 PM, Evan Cheng <evan.cheng at apple.com> wrote: > >> >> On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com> wrote: >> >>> >>> I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. >> >> I believe it's primary for address mode matching where only part of the GEP can be folded (depending on the instruction set). >&...

...ptrtoint/add/inttoptr) if the address mode is derived only from a single GEP. Thanks, Jun On Nov 12, 2013, at 7:14 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com> wrote: > >> >> I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. > > I believe it's primary for address mode matching where only part of the GEP can be folded (depending on the instruction set). > > Ev...

...heng at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> > Sent: Wednesday, November 20, 2013 7:48:13 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > > > On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- Original Message ----- > >> From: "Evan Cheng" <evan.cheng at apple.com> > >> To: "Junbum Lim" <junbums at gmail.com> > >> Cc:...

...m> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >> Sent: Wednesday, November 20, 2013 7:48:13 PM >> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >> >> >> On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> ----- Original Message ----- >>>> From: "Evan Cheng" <evan.cheng at apple.com> >>>> To: "Junbum Lim" <junbums at gmail....

Hi all! Attached a patch to preserve ProfileInfo in CodeGenPrepare. Would it be okay to commit such patches (that touch parts of LLVM to preserve ProfileInfo) without prior approval? Thanks, Andi -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-r81438.preserver.profile.info.patch Type: text/x-patch Size: 4480 bytes Desc:...

Hi all! Attached a patch to preserve ProfileInfo in CodeGenPrepare. Would it be okay to commit such patches (that touch parts of LLVM to preserve ProfileInfo) without prior approval? Thanks, Andi -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-r81438.preserver.profile.info.patch Type: text/x-patch Size: 4479 bytes Desc:...