search for: safelen

Yes, I think the 2 outcomes are: - the current spec is unclear and will be clarified - in order to support safelen() and even the simd construct itself, LLVM will require infrastructure work to know when a lexically backwards dependence may have been introduced. Jon -----Original Message----- From: Tian, Xinmin [mailto:xinmin.tian at intel.com] Sent: Monday, September 29, 2014 10:43 AM To: Renato Golin; Hal...

> Sorry for coming to the discussion so late. I have a couple of questions/comments: Actually, you're note is timely, because I'm planning to send out a patch (as soon as I update LangRef and rerun tests) that supports safelen but *not* lexical dependences. I don't need the safelen for Julia, but having done the work and seeing that OpenMP needs it, feel that I should finish the work to contribute it. Yes, safelen and lexical forward dependences are separable. I was initially under the impression that to implement...

...-----Original Message----- From: Humphreys, Jonathan [mailto:j-humphreys at ti.com] Sent: Thursday, August 28, 2014 11:53 AM To: Robison, Arch; Hal Finkel; Renato Golin; Alexander Musman (alexander.musman at gmail.com) Cc: LLVM Dev Subject: RE: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" Well, having not understood the connection between lexical dependence and the openMP simd construct yesterday, I inquired in the openMP community. If I understand the answer I got (from someone at Intel), the openMP simd construct is really asserting that no lexically backward dependences e...

More precisely, for a simd loop, if the safelen(VL) clause is specified, there should have no loop-carried lexical backward data dependency within the specified safe vector length VL. We will make this clear in the OpenMP 4.1 spec. Xinmin Tian (Intel) -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces...

...ing lexical position. The positions need not be consecutive, and may contain duplicates. * The second operand is the same as the first operand to llvm.mem.parallel_loop_access. It's second so that it can be omitted - see mention of inlining further below. The LoopID can have "llvm.loop.safelen" metadata. Here is an example with three accesses with positions {10, 15 17} and a safelen of 42. define void @foo(float* %a, float* %b) { entry: br label %for.body for.body: ; preds = %for.body, %entry ... %0 = load fl...

On 28 September 2014 22:09, Hal Finkel <hfinkel at anl.gov> wrote: > Thanks Xinmin! > > So we'll need a method to ensure the correct (partial) ordering. I thought that the idea was to avoid computing loop dependencies when safelen is specified, at least at that level. We might do it to a greater length, but we should assume it to be safe for distances < VL. We still need the method, I agree, for everything else, though. cheers, --renato

> I recommend that you send patches for an implementation > (including the Loop::GetAnnotatedVectorSafelen function > and associated updates to the vectorizer) for review. I expect to send the patches for review later this week. > Make sure to remember LangRef updates! Thanks for the reminder. > Also, looking at the original proposal again, I see no reason > to restrict this to an i3...

On 08/20, Arnold Schwaighofer wrote: > > > On Aug 20, 2014, at 8:08 AM, Robison, Arch <arch.robison at intel.com> wrote: > > > >> I recommend that you send patches for an implementation > >> (including the Loop::GetAnnotatedVectorSafelen function > >> and associated updates to the vectorizer) for review. > > > > I expect to send the patches for review later this week. > > > >> Make sure to remember LangRef updates! > > > > Thanks for the reminder. > > > >> Also, l...

----- Original Message ----- > From: "Roel Jordans" <r.jordans at tue.nl> > To: llvmdev at cs.uiuc.edu > Sent: Wednesday, August 13, 2014 5:57:15 AM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > > > > WHY CURRENT METADATA DOES NOT SUFFICE > > ------------------------------------- > > > > There are currently two pieces of metadata that come close, but > > miss the > > desired semantics. > > > > * llvm.loop.vectorize.width -...

...com> > To: "Johannes Doerfert" <doerfert at cs.uni-saarland.de> > Cc: llvmdev at cs.uiuc.edu, "Arch Robison" <arch.robison at intel.com> > Sent: Wednesday, August 20, 2014 11:29:16 AM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > > > On Aug 20, 2014, at 9:18 AM, Johannes Doerfert > > <doerfert at cs.uni-saarland.de> wrote: > > > > On 08/20, Arnold Schwaighofer wrote: > >> > >> > >> This means you would allow lexically forward dependencies which &g...

...quot;memory dependences are not a problem for vectorization widths up to n". I'd appreciate any comments before I spend time prototyping it. BACKGROUND ---------- OpenMP 4.0 allows the programmer to write something such as: void foo( float* a, int n, int k ) { #pragma omp simd safelen(8) for( int i=0; i<n; ++i ) { a[i] = 2*a[i+k]; } The pragma tells the compiler that the loop is safe to vectorize with a width of 8 or less. (I.e. it's up to the programmer to ensure that either k<=-8 or k>=0.) If safelen is missing, the safe width is unbo...

...Arnold Schwaighofer" <aschwaighofer at apple.com>, "Arch Robison" <arch.robison at intel.com>, "LLVM Dev" > <llvmdev at cs.uiuc.edu> > Sent: Wednesday, August 20, 2014 2:21:08 PM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > On 20 August 2014 20:18, Hal Finkel <hfinkel at anl.gov> wrote: > > I don't understand. I think that the numbering would need to be > > specific to the loop id. > > I thought the idea was to add it to every load/store in the loop. If > this loop then...

...Arnold Schwaighofer" <aschwaighofer at apple.com>, "Arch Robison" <arch.robison at intel.com>, "LLVM Dev" > <llvmdev at cs.uiuc.edu> > Sent: Wednesday, August 20, 2014 2:16:56 PM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > On 20 August 2014 18:24, Hal Finkel <hfinkel at anl.gov> wrote: > > Also, we should probably allow for missing access numbers, so long > > as everything is in order (because the optimizer might eliminate > > some of them). Some memory-access instructions mig...

...roject DiscoPoP (Entry provided) (Zhen Li) 3. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) 4. Re: Functions with unnamed parameters in LLVM IR (Tim Northover) 5. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) 6. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) 7. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) 8. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) 9. Re: Addressing const reference in ArrayRef (David Blaikie) 10. Re: Proposal for ""llvm.mem.vectorize.safelen&...

...ry provided) (Zhen Li) > 3. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > 4. Re: Functions with unnamed parameters in LLVM IR (Tim Northover) > 5. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > 6. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > 7. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > 8. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > 9. Re: Addressing const reference in ArrayRef (David Blaikie) > 10. Re: Proposal for ""llvm.me...

...i) > > 3. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > 4. Re: Functions with unnamed parameters in LLVM IR (Tim Northover) > > 5. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > 6. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > > 7. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > 8. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > > 9. Re: Addressing const reference in ArrayRef (David Blaikie) > > 10. Re: Proposal for...

...3. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > > 4. Re: Functions with unnamed parameters in LLVM IR (Tim Northover) > > > 5. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > > 6. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > > > 7. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > > 8. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > > > 9. Re: Addressing const reference in ArrayRef (David Blaikie) > > >...

On 12 August 2014 18:49, Johannes Doerfert <doerfert at cs.uni-saarland.de> wrote: > I recently submitted a patch to the list [1] which would allow Polly to > extract the dependency distance for each analyzable loop. While the > distance is often not constant but parametric we would also need to > version the vectorized loop based on the actual runtime values. Since this is a

Hi all, I am currently looking into how "#pragma omp for simd" is actually recognized in llvm. To my knowledge, clang will parse it and set metadata in IR to indicate this force-vectorization hint and later optimization passes would read it and vectorize the marked loop. Therefore, the loop should be vectorized even the compiler think it might not be safe to do so? So my