search for: memoryaccess

Dear community, the next step of the "Improvement of vectorization process in Polly" project is to implement the packing transformation described in http://www.cs.utexas.edu/users/flame/pubs/TOMS-BLIS-Analytical.pdf. I had a discussion with Tobias and we decided that a packing transformation is in many ways a data-layout transformation that will require to introduce a new array, copy

...tedPHIs.being() + StartingPHISize” it will be finite but given that InsrtedPHIs is finite. I have a case where one element(same element is appened to InsertedPHIs) is added to InsertedPHIs every time fixupDefs is invoked. I traced the issue why this was happening. template <class RangeType> MemoryAccess *MemorySSAUpdater::tryRemoveTrivialPhi(MemoryPhi *Phi, RangeType &Operands) { // Detect equal or self arguments MemoryAccess *Same = nullptr; for (auto &Op : Operands) { // If the same or self, good so far if (Op == Phi || Op...

...that InsrtedPHIs is > finite. > > > > I have a case where one element(same element is appened to InsertedPHIs) > is added to InsertedPHIs every time fixupDefs is invoked. I traced the > issue why this was happening. > > > > template <class RangeType> > > MemoryAccess *MemorySSAUpdater::tryRemoveTrivialPhi(MemoryPhi *Phi, > > RangeType &Operands) { > > // Detect equal or self arguments > > MemoryAccess *Same = nullptr; > > for (auto &Op : Operands) { > > // If the...

...SSA which leads to extra walking of MemoryDefs to not regress some EarlyCSE test cases. This isn’t a huge deal, I’m just wondering if it is intentional or something that just hasn’t been gotten to yet. 2) There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed. In the case I’m seeing, a call node is removed from MemorySSA which causes CachingMemorySSAWalker::invalidateInfo() to clear the CachedUpwardsClobberingCall map. However, this same call node is present as a value in the CachedUpwardsClobberingAccess map, so when a la...

Hi All, I'm looking into converting LICM to use MemorySSA instead of AliasSets to determine when it is safe to hoist/sink/promote loads and stores to get around the issue of alias set collapse (see discussion [1]). I have a prototype implementation, but have run into two issues that I could use input from the designers of MemorySSA to resolve: 1) Is MemorySSA intended to be

...compile started ---------------------> Integer args substituted: offset = 32, ptrValue = 47248855040 offset = 40, ptrValue = 47246749696 offset = 48, ptrValue = 47247802368 offset = 16, value = 64 offset = 20, value = 64 offset = 24, value = 64 MemoryAccess to pointer: float* inttoptr (i64 47246749696 to float*) { Stmt__12_cloned_[i0, i1, i2] -> MemRef_nttoptr (i64 47246749696 to float*)[4096i0 + 64i1 + i2] } allocSize: 4 storeSize: 4 replacedBy: { Stmt__12_cloned_[i0, i1, i2] -> NULL[o0] : o0 >= 47246749696 + 16384i0 + 256i1...

2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > FWIW: We hit a subset of this issue with MemorySSA (which subclasses value > for the MemoryAccess's, etc), and it was discussed as well during > PredicateInfo. > > NewGVN has a variant the same issue as well, where it actually creates > unattached (IE not in a basic block) new instructions just so it can analyze > them. > > IMHO, some nice way to make virtual forms over...

On 01/01/2013 02:45 PM, Duncan Sands wrote: > Hi Dmitry, > >> >> In our compiler we use a modified version LLVM Polly, which is very >> sensitive to >> proper code generation. Among the number of limitations, the loop region >> (enclosed by phi node on induction variable and branch) is required to >> be free >> of additional memory-dependent

On Sat, Sep 23, 2017 at 9:55 AM, Godala, Bhargav-reddy < Bhargav-reddy.Godala at amd.com> wrote: > > With regards > Bhargav Reddy Godala > Software Engineer 2 > Bangalore, India > E-mail: Bhargav-reddy.Godala at amd.com Ext 30678 > > > > On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Sat, Sep 23, 2017 at

With regards Bhargav Reddy Godala Software Engineer 2 Bangalore, India E-mail: Bhargav-reddy.Godala at amd.com<mailto:Bhargav-reddy.Godala at amd.com> Ext 30678 On 23-Sep-2017, at 9:27 PM, Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> wrote: On Sat, Sep 23, 2017 at 8:38 AM, Godala, Bhargav-reddy via llvm-dev <llvm-dev at

...tional or something that just hasn’t been gotten to yet. George is working on the optimizations, of which this is one. I think this is one of the ones his current patch (under review) addresses. 2) There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed. In the case I’m seeing, a call node is removed from MemorySSA which causes CachingMemorySSAWalker::invalidateInfo() to clear the CachedUpwardsClobberingCall map. However, this same call node is present as a value in the CachedUpwardsClobberingAccess map, Unless i...

...function called by ISL of which I'm not a very expert of. This is the backtrace of the manually terminated process in gdb: (gdb) bt #0 0x0000000101828422 in __gmpn_gcd_1 () #1 0x00000001018102ea in __gmpz_gcd () #2 0x0000000101cd0f33 in isl_aff_scale_down () #3 0x0000000101a5a175 in polly::MemoryAccess::MemoryAccess (this=0x101911ed0, Access=@0x10190fc48, Statement=0x10190ffa0) at /Users/Kariddi/Documents/Sviluppo/Tesi/llvm/tools/polly/lib/Analysis/ScopInfo.cpp:308 #4 0x0000000101a5b22a in polly::ScopStmt::buildAccesses (this=0x10190ffa0, tempScop=@0x10190eb70, CurRegion=@0x10190eed0) at /Users/...

...mailto:llvmdev at meinersbur.de>> wrote: > > 2017-10-14 5:03 GMT+02:00 Daniel Berlin <dberlin at dberlin.org > <mailto:dberlin at dberlin.org>>: > > FWIW: We hit a subset of this issue with MemorySSA (which > subclasses value > > for the MemoryAccess's, etc), and it was discussed as well during > > PredicateInfo. > > > > NewGVN has a variant the same issue as well, where it actually > creates > > unattached (IE not in a basic block) new instructions just so it > can analyze > >...

...; > Integer args substituted: > offset = 32, ptrValue = 47248855040 > offset = 40, ptrValue = 47246749696 > offset = 48, ptrValue = 47247802368 > offset = 16, value = 64 > offset = 20, value = 64 > offset = 24, value = 64 > MemoryAccess to pointer: float* inttoptr (i64 47246749696 to float*) > { Stmt__12_cloned_[i0, i1, i2] -> MemRef_nttoptr (i64 47246749696 to > float*)[4096i0 + 64i1 + i2] } > allocSize: 4 storeSize: 4 > replacedBy: { Stmt__12_cloned_[i0, i1, i2] -> NULL[o0] : o0 >= > 47246...

...tional or something that just hasn’t been gotten to yet. George is working on the optimizations, of which this is one. I think this is one of the ones his current patch (under review) addresses. 2) There seems to be a bug in the CachingMemorySSAWalker invalidation causing it to return MemoryAccess nodes that have been removed. In the case I’m seeing, a call node is removed from MemorySSA which causes CachingMemorySSAWalker::invalidateInfo() to clear the CachedUpwardsClobberingCall map. However, this same call node is present as a value in the CachedUpwardsClobberingAccess map, Unless i...

..., 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@ -732,7 +732,7 @@ private: > MemoryPhi *getMemoryAccess(const BasicBlock *) const; > template <class T, class Range> T *getMinDFSOfRange(const Range &) > const; > unsigned InstrToDFSNum(const Value *V) const { > - assert(isa<Instruction>(V) && "This should not be used for > MemoryAccesses"); >...

>Do you recall the arguments why it was considered a bad idea? Felt like long time ago, but it turned out that was actually just a bit over a year ago. Here's the thread. http://lists.llvm.org/pipermail/llvm-dev/2016-August/104079.html Only a few explicitly responded, but I took that as silent majority was satisfied with the responses. Prior to that thread, I also pinged HPC oriented LLVM

...> llvm-dev at lists.llvm.org> wrote: >> >>> What do you think about this patch? >>> >>> --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp >>> +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp >>> @@ -732,7 +732,7 @@ private: >>> MemoryPhi *getMemoryAccess(const BasicBlock *) const; >>> template <class T, class Range> T *getMinDFSOfRange(const Range &) >>> const; >>> unsigned InstrToDFSNum(const Value *V) const { >>> - assert(isa<Instruction>(V) && "This should not be used for...

...#39;s sufficient. Suppose, for instance, that I >> wanted to insert a MemoryDef between 1 and 2 in the below AccessList: >> >> >> 0 = MemoryDef(liveOnEntry) >> 1 = MemoryDef(0) >> 2 = MemoryDef(1) >> 3 = MemoryUse(1) >> >> Invoking createMemoryAccess followed by RAUW of 1's uses with 4 would >> result in: >> .... >> " >> >> Which is why this is not the way one does this, anywhere. >> If you wish to *replace* an existing access, the normal way is: >> >> > As my original post indicates,...

Mmm I found out a very strange behavior (to me) of the SCEV analysis of the loop bound of the external loop I posted. When in ScopDetection it gets the SCEV of the external loop bound in the "isValidLoop()" function with: const SCEV *LoopCount = SE->getBackedgeTakenCount(L); It returns a SCEVCouldNotCompute, but if I change the "if" block inside the loop from: if