search for: codegenprepar

Displaying 20 results from an estimated 231 matches for "codegenprepar".

Did you mean: codegenprepare
2014 Feb 19
4
[LLVMdev] [RFC] CodeGenPrepare will eventually introduce dependencies to libLLVMCodeGen in libLLVMScalarOpts
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...
2018 Jun 29
2
Cleaning up ‘br i1 false’ cases in CodeGenPrepare
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...
2018 Jun 29
2
Cleaning up ‘br i1 false’ cases in CodeGenPrepare
...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...
2007 Jun 18
0
[LLVMdev] alias information on machine instructions
...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...
2013 Jan 17
1
[LLVMdev] Regarding codegenprepare transformations
...+ 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...
2008 Sep 24
1
[LLVMdev] llvm broken?
/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...
2013 Nov 12
2
[LLVMdev] sinking address computing in CodeGenPrepare
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...
2013 Nov 12
2
[LLVMdev] sinking address computing in CodeGenPrepare
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...
2013 Nov 12
0
[LLVMdev] sinking address computing in CodeGenPrepare
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...
2013 Nov 13
0
[LLVMdev] sinking address computing in CodeGenPrepare
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...
2020 May 15
3
ConstantFoldTerminator doesn't delete trivially dead phi inputs
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...
2013 Nov 21
2
[LLVMdev] sinking address computing in CodeGenPrepare
----- 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...
2007 Jun 15
6
[LLVMdev] alias information on machine instructions
...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...
2013 Nov 21
0
[LLVMdev] sinking address computing in CodeGenPrepare
...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 &...
2013 Nov 21
0
[LLVMdev] sinking address computing in CodeGenPrepare
...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). >&...
2013 Nov 20
2
[LLVMdev] sinking address computing in CodeGenPrepare
...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...
2013 Nov 21
3
[LLVMdev] sinking address computing in CodeGenPrepare
...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:...
2013 Nov 22
0
[LLVMdev] sinking address computing in CodeGenPrepare
...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....
2009 Sep 10
0
[LLVMdev] [PATCH] Preserver ProfileInfo in CodeGenPrepare
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:...
2009 Sep 10
0
[LLVMdev] [PATCH] Preserver ProfileInfo in CodeGenPrepare
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:...