search for: optimizememoryinst

Hey guys, I'm working on the S3D Benchmark and notice that CodeGenPrepare::OptimizeMemoryInst(...) in lib/Transforms/Scalar/CodeGenPrepare.cpp isn't scaling well. A whopping 99.3% of the compilation time for one file is spent in this function. The User Time for this compilation is 3166 seconds with a stock LLVM 3.1. If I disable the calls to OptimizeMemoryInst(...), the compilation time...

Dear Community, I'm trying to implement optimization described in PR26223 and meet the following bail out condition in CodeGenPrepare::optimizeMemoryInst. // Break use-def graph loops. if (!Visited.insert(V).second) { Consensus = nullptr; break; } So while traversing thorough phi nodes from memory instruction to find addr mode we bail out if we meet some instruction twice. Does anybody know/remember what is the reason for t...

When multiple GEPs or other operations are used for the address calculation, OptimizeMemoryInst() performs address matching and determines a final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block so that ISel could have better chance to fold address computation into LDRs and STRs. However, OptimizeMemoryInst() seems to do this transformat...

...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 addressing expression as a simple form (e.g., > > ptrtoint/add/inttoptr) and sinks it into user's block so that ISel > > could have better chance to fold address computation into LDRs and > > STRs. However, OptimizeM...

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 addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block so that ISel could have better chance to fold address computation into LDRs and STRs. However, OptimizeMemoryInst() seems to do this transformat...

...odeGenPrepare > >> > >> > >> 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 addressing expression as a simple form (e.g., > >>> ptrtoint/add/inttoptr) and sinks it into user's block so that > >>> ISel > >>> could have better chance to fold address computation into L...

...nto 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 = getelement...

...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 addressing expression as a simple form (e.g., >>> ptrtoint/add/inttoptr) and sinks it into user's block so that ISel >>> could have better chance to fold address computation into LDRs and >>> STRs. Howeve...

...t;> >>>> >>>> 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 addressing expression as a simple form (e.g., >>>>> ptrtoint/add/inttoptr) and sinks it into user's block so that >>>>> ISel >>>>> could have better chance to fold address comput...

...ch, 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: >>> %z...

...>>>>> 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 addressing expression as a simple form (e.g., >>>>>> ptrtoint/add/inttoptr) and sinks it into user's block so that >>>>>> ISel >>>>>> could have better chance to fol...

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 inbounds %struct.SS* %a2, i32...

...t; 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 addressing expression as a simple form (e.g., >>>>>>> ptrtoint/add/inttoptr) and sinks it into user's block so that >>>>>>> ISel >>>>>>> could have bett...

...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 = getelementptr inbounds %s...

Hi, I want to improve the way CGP sinks the incoming values of a PHI node towards memory accesses. Improving it means a lot to some of our key benchmarks, and I believe can benefit many general cases as well. CGP's OptimizeMemoryInst function handles PHI nodes by running AddressingModeMatcher on all incoming values to see whether they reach consensus on the addressing mode. It does a reasonably good job in sinking a PHI node if its incoming values are used only once (by the PHI node) and share the same base register and offset....

On Thu, Oct 31, 2019 at 11:17 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Oct 31, 2019 at 8:50 AM kamlesh kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Devs, >> Consider testcase here >> https://godbolt.org/z/qHZzqw >> When optimization is O1 or above it produces unoptimized code >> because it

...lvm::SelectionDAG::getMemcpy(llvm::SDValue, llvm::DebugLoc, llvm::SDValue, llvm::SDValue, llvm::SDValue, unsigned int, bool, bool, llvm::Value const*, unsigned long long, llvm::Value const*, unsigned long long)in libLLVMSelectionDAG.a(SelectionDAG.cpp.o) (anonymous namespace)::CodeGenPrepare::OptimizeMemoryInst(llvm::Instruction*, llvm::Value*, llvm::Type const*, llvm::DenseMap<llvm::Value*, llvm::Value*, llvm::DenseMapInfo<llvm::Value*>, llvm::DenseMapInfo<llvm::Value*> >&) in libLLVMScalarOpts.a(CodeGenPrepare.cpp.o) CoerceAvailableValueToLoadTyp...