search for: gvnhoist

...ransformation would look like this: USE(M0) // corresponding to `v = load q` M1 = DEF(M0) // corresponding to `store 10, p` Reordering these two nodes does not break syntactic dependency, hence additional flow-sensitive analysis is needed to check whether reordering is valid. To my understanding, GVNHoist seems to do that: Memory operations in basic blocks are checked by GVNHoist::hasMemoryUse(). If USE nodes of MemorySSA also have left-hand side, we can correctly represent this kind of reorderability IMHO. For the example above: U1 = USE(M0) // corresponding to `v = load q` M1 = DEF(M0, U1) //...

When we erase a memory access instruction, existing passes using memory ssa like GVN, NewGVN, GVNHoist and EarlyCSE uses MemorySSAUpdater to do the update before the instruction is erased. However, if we call llvm::RecursivelyDeleteTriviallyDeadInstructions to find out dead instruction recursively and memory access instructions may be erased inside the recursive process, we need a way to update Mem...

Can you share you compile-time and memory footprint measurements at least for CTMark? For a new pass/feature it would be great to share this with the community before you commit. Or did I miss them? Thanks Gerolf > On Jun 27, 2017, at 3:26 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > EarlyCSE w/ MemorySSA has been enabled by default as of r306477 >

...ion > '-enable-earlycse-memssa' > > (or '-enable-npm-gvn-hoist' if you're using the new pass manager) that > you > > can be used to test this change out. > > > > Not that I don't trust your self-hosting test strategy, but other > passes (e.g. GVNHoist or NewGVN) showed us that's not quite enough to > declare victory. I'll be much more confident if we can do at least a > round of fuzzing. > > Thanks, > > -- > Davide > _______________________________________________ > LLVM Developers mailing list > llvm-dev at...

...break syntactic dependency, >> This is true in regular SSA as well :) >> It just happens that memory is different due to aliasing. >> >> > hence additional flow-sensitive analysis is needed to check whether reordering is valid. >> >> > To my understanding, GVNHoist seems to do that: >> > Memory operations in basic blocks are checked by >> > GVNHoist::hasMemoryUse(). >> > >> Correct. >> >> > >> > If USE nodes of MemorySSA also have left-hand side, we can correctly >> > represent this kind of reo...

Hi All, I'd like to switch the function simplification run of EarlyCSE to use MemorySSA by default. This change has been in tree for a while and I've done benchmark and self-hosting testing on both aarch64 and x86, but I wanted to give other folks with different tests/targets a chance to try this out before I flip the switch. I've added an option

I have tried running both gvn and newgvn but it did not helped in hoisting the alias checks: Please check, maybe I have missed something. <TestCase> void foo (char *A, char *B, char *C, int len) { int i = 0; for (i=0 ; i< len; i++) A[i] = B[i] + C[i]; } <Command> $ opt –O3 –gvn test.ll –o test.opt.ll $ opt –O3 –newgvn test.ll –o test.opt.ll “test.ll” is attached, it

...fects. >> > > While I agree it can be lazy, and should be an analysis, i'm, again, > really not sure which passes you are thinking about here that do code > sinking/speculation that won't need it. > > Here's the list definitely needing it right now: > GVN > GVNHoist > LICM > LoadCombine > LoopReroll > LoopUnswitch > LoopVersioningLICM > MemCpyOptimizer > MergedLoadStoreMotion > Sink > > The list is almost certainly larger than this, this was a pretty trivial > grep and examination. > (and doesn't take into account bugs,...

> On Jul 21, 2016, at 7:45 AM, Philip Reames <listmail at philipreames.com> wrote: > > Joining in very late, but the tangent here has been interesting (if rather OT for the original thread). > > I agree with Danny that we might want to take a close look at how we model things like maythrow calls, no return, and other implicit control flow. I'm not convinced that moving

...Ayal <ayal.zaks at intel.com>; Renato Golin <renato.golin at linaro.org>; mkuper at google.com; Mehdi Amini <mehdi.amini at apple.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [Proposal][RFC] Epilog loop vectorization Sorry I misunderstood, gvn/newgvn/gvnhoist cannot help here as these checks are not dominated by all paths. Regards, Ashutosh From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Tuesday, February 28, 2017 6:58 PM To: Nema, Ashutosh <Ashutosh.Nema at amd.com<mailto:Ashutosh.Nema at amd.com>> Cc: anemet at apple.com<mai...

...; <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>>; llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > *Subject:* RE: [llvm-dev] [Proposal][RFC] Epilog loop vectorization > > Sorry I misunderstood, gvn/newgvn/gvnhoist cannot help here as > these checks are not dominated by all paths. > > Regards, > > Ashutosh > > *From:*Daniel Berlin [mailto:dberlin at dberlin.org] > *Sent:* Tuesday, February 28, 2017 6:58 PM > *To:* Nema, Ashutosh <Ashutosh.Nema at amd.com &...

...; While I agree it can be lazy, and should be an analysis, i'm, again, >> really not sure which passes you are thinking about here that do code >> sinking/speculation that won't need it. >> >> Here's the list definitely needing it right now: >> GVN >> GVNHoist >> LICM >> LoadCombine >> LoopReroll >> LoopUnswitch >> LoopVersioningLICM >> MemCpyOptimizer >> MergedLoadStoreMotion >> Sink >> >> The list is almost certainly larger than this, this was a pretty trivial >> grep and examination. &g...

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...

...<mehdi.amini at apple.com >> <mailto:mehdi.amini at apple.com>>; llvm-dev <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> >> *Subject:*RE: [llvm-dev] [Proposal][RFC] Epilog loop vectorization >> Sorry I misunderstood, gvn/newgvn/gvnhoist cannot help here as these >> checks are not dominated by all paths. >> Regards, >> Ashutosh >> *From:*Daniel Berlin [mailto:dberlin at dberlin.org] >> *Sent:*Tuesday, February 28, 2017 6:58 PM >> *To:*Nema, Ashutosh <Ashutosh.Nema at amd.com >> <mai...

...> (or '-enable-npm-gvn-hoist' if you're using the new pass manager) that >>> you >>> > can be used to test this change out. >>> > >>> >>> Not that I don't trust your self-hosting test strategy, but other >>> passes (e.g. GVNHoist or NewGVN) showed us that's not quite enough to >>> declare victory. I'll be much more confident if we can do at least a >>> round of fuzzing. >>> >>> Thanks, >>> >>> -- >>> Davide >>> __________________________________...

...pple.com>>; >> llvm-dev <llvm-dev at lists.llvm.org >> <mailto:llvm-dev at lists.llvm.org>> >> *Subject:* RE: [llvm-dev] [Proposal][RFC] Epilog loop >> vectorization >> >> Sorry I misunderstood, gvn/newgvn/gvnhoist cannot help here >> as these checks are not dominated by all paths. >> >> Regards, >> >> Ashutosh >> >> *From:*Daniel Berlin [mailto:dberlin at dberlin.org] >> *Sent:* Tuesday, February 28, 2017 6:58 PM >>...