search for: addruntimecheck

...nse over ‘hasAccessToLoopInvariantAddress’. Right but it’s the address that’s invariant not the store so hasLoopInvariantStore is a misleading name. How about hasStoreToLoopInvariantAddress? > > You will also need to generate the memchecks for such accesses in > > canCheckPtrAtRT and addRuntimeCheck. Without those memchecks passing, > > the result of the dependence analysis is incorrect. > I did not understood this point correctly, I feel the current functionality take cares of it > And we do not need any new handling for these invariant stores in “canCheckPtrAtRT” and “addRuntime...

...1 DEBUG(dbgs() << "LV: We don't allow storing to uniform addresses\n"); > 4012 return false; > 4013 } > No, not hasLoopInvariantStore but hasAccessToLoopInvariantAddress. You will also need to generate the memchecks for such accesses in canCheckPtrAtRT and addRuntimeCheck. Without those memchecks passing, the result of the dependence analysis is incorrect. Adam > Adam > > Regards, > Ashutosh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/b74736d1/atta...

Hi Sergei, "addRuntimeCheck" inserts code that checks that two or more arrays are disjoint. I looked at the code and it looks fine. We generate PHIs in the order that they appear in a vector. The values are inserted in 'canVectorizeMemory', which also looks fine. Please let me know if you think I missed something...

...undation > -----Original Message----- > From: Nadav Rotem [mailto:nrotem at apple.com] > Sent: Tuesday, January 29, 2013 11:15 AM > To: Sergei Larin > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Apparent indeterminism in PreVerifier > > Hi Sergei, > > "addRuntimeCheck" inserts code that checks that two or more arrays are > disjoint. I looked at the code and it looks fine. We generate PHIs in > the order that they appear in a vector. The values are inserted in > 'canVectorizeMemory', which also looks fine. Please let me know if you > thin...

...e----- >> From: Nadav Rotem [mailto:nrotem at apple.com] >> Sent: Tuesday, January 29, 2013 11:15 AM >> To: Sergei Larin >> Cc: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Apparent indeterminism in PreVerifier >> >> Hi Sergei, >> >> "addRuntimeCheck" inserts code that checks that two or more arrays are >> disjoint. I looked at the code and it looks fine. We generate PHIs in >> the order that they appear in a vector. The values are inserted in >> 'canVectorizeMemory', which also looks fine. Please let me know if y...

Nadav, As I peel this onion, it looks like you might know something about InnerLoopVectorizer::addRuntimeCheck. What does it do, and can it be causing the below described issue? Could resuming somehow (indeterministically) switch the order of PHIs in the original code? Thanks a lot. Sergei. --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > -----O...

Hello everybody, I have a case of suspected indeterminism and I would like to verify that it is not a known issue before I dig deep into it. It seems to happen during PreVerifier pass ("Preliminary module verification"). The little I understand/assume about it, a verifier pass is not supposed to change the code (or is it?) but in debug stream I see the following: Common predecessor:

...on. As you will hopefully find this will make the LAA more generic. I will cc you on the patches. > It’s good to make some of the classes & function more generic and reusable. > Will be covering some of the points in this mail. > > RuntimeCheckEmitter > “RuntimeCheckEmitter::addRuntimeCheck” > While creating runtime check I have found, some of the things are not getting considered. > 1) No need to check if two read only pointers intersect. > 2) Only need to check pointers between two different dependency sets. > 3) Only need to check pointers in the same alias set > &...

Hi Ashutosh, Have you been following the recent Loop Access Analysis work? LAA was split out from the Loop Vectorizer that have been performing the kind of loop versioning that you describe. The main reason was to be able to share this functionality with other passes. Loop Access Analysis is an analysis pass that computes basic memory dependence and the runtime checks. The versioning decision

...h.Nema at amd.com> wrote: > > > I am about to post the patches to make LAA suitable for Loop Distribution. As you will hopefully find this will make the LAA more generic. I will cc you on the patches. > > Sure Adam. > > RuntimeCheckEmitter > “RuntimeCheckEmitter::addRuntimeCheck” > While creating runtime check I have found, some of the things are not getting considered. > 1) No need to check if two read only pointers intersect. > 2) Only need to check pointers between two different dependency sets. > 3) Only need to check pointers in the same alias set > &...

Hi Ashutosh, > On Mar 16, 2015, at 9:06 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Hi Adam, > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Wednesday, March 11, 2015 10:48 AM > To: Nema, Ashutosh > Cc: llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] RFC: Loop

I like to propose a new loop multi versioning optimization for LICM. For now I kept this for LICM only, but it can be used in multiple places. The main motivation is to allow optimizations stuck because of memory alias dependencies. Most of the time when alias analysis is unsure about memory access and it says may-alias. This un surety from alias analysis restrict some of the memory based