similar to: [LLVMdev] Alias-based Loop Versioning

----- Original Message ----- > From: "Dibyendu Das" <Dibyendu.Das at amd.com> > To: "Adam Nemet" <anemet at apple.com>, "Dev" <llvmdev at cs.uiuc.edu>, "Ashutosh Nema" <Ashutosh.Nema at amd.com>, "Hal > Finkel" <hfinkel at anl.gov> > Sent: Saturday, May 23, 2015 5:45:27 AM > Subject: RE: [LLVMdev]

It’s a good thought in general Adam, but I worried about following scenarios: 1) As Dibyendu already mentioned Check1 + Check2 is not very clear. If your intent is superset/union of check1 & check2 then I’m not sure it will always help passes those needs smaller checks (i.e. loop distribution) Every pass has a different need of runtime check, i.e. vectorizer checks each memory against all

Thanks for the feedback. Sounds like that at this point in time we can’t really settle on a single strategy. We probably want to support all of these uses-cases: 1. A common early loop-versioning pass, probably fairly conservative initially (e.g. if you need a single memcheck to remove all may-aliasing from a hight-trip-count loop it’s probably a good idea to version). Even if the pass would

> On Mar 20, 2015, at 8:02 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > > Yes, this is what I was proposing above and here ;): > Thanks Adam it’s for confirming J NP :). > > > No, not hasLoopInvariantStore but hasAccessToLoopInvariantAddress. > Its only for invariant stores[not loads], Using ‘hasLoopInvariantStore’ (or a name with invariant store)

> On Mar 19, 2015, at 9:46 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > Thanks Adam for your reply. > > From: Adam Nemet [mailto:anemet at apple.com <mailto:anemet at apple.com>] > Sent: Friday, March 20, 2015 3:23 AM > To: Nema, Ashutosh > Cc: Hal Finkel; Philip Reames; llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu> > Subject:

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

> On Mar 5, 2015, at 10:33 PM, Nema, Ashutosh <Ashutosh.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

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

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

>it cannot afford large size masks for large vectors So, even a standard way of vectorizing remainder in masked or unmasked fashion wouldn’t work, I suppose. Ouch. I suppose VPlan should be able to model this kind of gigantic remainder vector code (when the time comes). Not pretty at all, though. Now, be fully aware that Direction #2 is really a poor (or rather extremely poor) person’s

> On Mar 3, 2015, at 1:29 AM, Nema, Ashutosh <Ashutosh.Nema at amd.com <mailto:Ashutosh.Nema at amd.com>> wrote: > > Hi Adam, > > Thanks for looking into LoopVersioning work. > > I have gone through recent LoopAccessAnalysis changes and found some of the stuff > overlaps (i.e. runtime memory check, loop access analysis etc.). LoopVersioning can > use

Summarizing the discussion on the implementation approaches. Discussed about two approaches, first running ‘InnerLoopVectorizer’ again on the epilog loop immediately after vectorizing the original loop within the same vectorization pass, the second approach where re-running vectorization pass and limiting vectorization factor of epilog loop by metadata. <Approach-2> Challenges with

Hi Hameeza, Aside from Ashutosh's patch..... When the vector width is that large, we can't keep vectorizing remainder like below. It'll be a huge code size if nothing else ---- hitting ITLB miss because of this is very bad, for example. VF=2048 // main vector loop VF=1024 // vectorized remainder 1 VF=512 // vectorized remainder 2 ... Vectorize remainder until trip count is

Thanks for looking into this. 1) Issues with re running vectorizer: Vectorizer might generate redundant alias checks while vectorizing epilog loop. Redundant alias checks are expensive, we like to reuse the results of already computed alias checks. With metadata we can limit the width of epilog loop, but not sure about reusing alias check result. Any thoughts on rerunning vectorizer with reusing

On 02/22/2017 11:52 AM, Adam Nemet via llvm-dev wrote: > Hi Ashutosh, > >> On Feb 22, 2017, at 1:57 AM, Nema, Ashutosh via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> This is a proposal about epilog loop vectorization. >> Currently Loop Vectorizer inserts an epilogue loop for handling loops

Hi, We'd like to propose new Loop Distribution pass. The main motivation is to allow partial vectorization of loops. One such example is the main loop of 456.hmmer in SpecINT_2006. The current version of the patch improves hmmer by 24% on ARM64 and 18% on X86. The goal of the pass is to distribute a loop that can't be vectorized because of memory dependence cycles. The pass splits

> On Feb 22, 2016, at 6:27 AM, Vikram TV <vikram.tarikere at gmail.com> wrote: > > > > On Fri, Feb 19, 2016 at 10:46 PM, Vikram TV <vikram.tarikere at gmail.com <mailto:vikram.tarikere at gmail.com>> wrote: > Hi, > > Thanks for the reply. Few thoughts inlined. > > On Fri, Feb 19, 2016 at 8:00 AM, Adam Nemet <anemet at apple.com

Hello. Could you please tell me why the first loop of the following program (also maybe the commented loop) doesn't get vectorized with LoopVectorize (from a recent LLVM build from the SVN repository from Jun 2018)? typedef short TYPE; TYPE data[1400][1200]; void kernel_covariance(int m, int n, TYPE mean[1200]) { int i, j, k; for (j = 0; j < m; j++) { mean[j] =

Hi, Thanks for the reply. Few thoughts inlined. On Fri, Feb 19, 2016 at 8:00 AM, Adam Nemet <anemet at apple.com> wrote: > Hi Vikram, > > On Feb 18, 2016, at 9:21 AM, Vikram TV via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I have created a patch (up for review at: http://reviews.llvm.org/D17386) > that does Loop Fusion implementation.

Dear R-user, I'm trying to compare two sets of results and wanted to find out which element in the two data frame/matrix are different. I wrote the following function and it works ok, and gives me a long list of "good" as outcomes. CHECK<- function (x = "file1", y = "file2") { for (i in 1:nrow(x)) { for (j in 1:ncol(x)) { if (x[i, j]