similar to: [LLVM] (RFC) Addition/Support of new Vectorization Pragmas in LLVM

On 8/8/19 2:03 PM, Hal Finkel wrote: Hi, First, as a high-level note, you posted a link to a Google doc, and at the end of the Google doc, you have a list of questions that you'd like answered. In the future, please put the questions directly in the email. For one thing, more people will read your email than will open your Google doc. Second, having the questions in the email should allow a

> There is a fundamental problem with the way that ivdep is defined by Intel's current documentation, at least for C/C++. As you note in your Google doc, it essentially says that the optimizer may ignore loop-carried dependencies except for those dependencies it can definitely prove are present. These are not semantics that any other compiler can actually replicate, and is not equivalent to

vecremainder/novecremainder: Should the pragma simply call the vectorizer to attempt to vectorize the remainder loop, or should the vectorizer use a different method? > > Something like that. There were patches posted at some point to enable tail-loop vectorization. At this point, I imagine that you'd construct a VPlan with the vectorized tail. Yep, committed in

Sorry if I'm generating noise - but is this the right place to come for information about the Clang compiler? I can't find an actual community forum for Clang but it often seems to get mentioned in the same context as LLVM. Or if I'm in the wrong place... can anyone direct me to an actual 'Clang' forum or mailing list? Many thanks, John -------------- next part

On Thursday 11 February 2010 13:31:58 David Greene wrote: > > Putting a bit (or multiple bits) in MachineMemOperand for this > > would also make sense. > > Is there any chance a MachineMemOperand will be shared by multiple > instructions? So I tried to do this: %r8 = load <2 x double>* %r6, align 16, !"nontemporal" and the assembler doesn't like it.

On Thursday 11 February 2010 14:05:21 David Greene wrote: > Either ParseLoad and probably other instructions need to look for metadata > explicitly or ParseOptionalCommaAlign needs to know about general metadata. > > My inkling is to fix ParseOptionalCommaAlign. Sound reasonable? Well, that's a rat's nest. I backed up and thought maybe I have the metadata syntax wrong. So

The current specification of the behavior of the !nontemporal attribute in LLVM, and the __builtin_nontemporal_* functions in Clang, is rather spartan and underspecified. In effect, it says the following things: * Atomic !nontemporal has no defined semantics * !nontemporal may use special instructions to save cache bandwidth, such as "MOVNT" on x86. What is crucially lacking

________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> Sent: Tuesday, April 28, 2020 4:54 PM To: Cranmer, Joshua <joshua.cranmer at intel.com> Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Nontemporal memory accesses and fences I see

On May 23, 2013, at 8:52 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > > !0 = metadata !{ metadata !1, metadata !2 } > !1 = metadata !{ metadata !"llvm.loop.parallel" } > !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } > > I'm not even sure you would need the llvm.loop.parallel anymore since the

The ivdep pragma is designed to do exactly what the name states - ignore vector dependencies.  Cray Research first implemented this in 1978 in their CFT compiler, and has supported it since. This pragma is typically used by application developers who want vectorized code when the compiler cannot automatically determine safety; it is not equivalent to the OpenMP SIMD pragma in that the compiler is

On 03/03/2013 02:34 PM, Tobias Grosser wrote: > Meaning they are due to an array or pointer access. What about loop-scope arrays? void foo(long *A, long b) { long i; #pragma ivdep for (i = 0; i < 100; i++) { long t[100]; t[0] = i + 2; A[i] = A[i+b] + t[0]; } } Clang places the alloca for t to the entry block, creating a new race condition.

On May 23, 2013, at 10:37 AM, Cameron McInally <cameron.mcinally at nyu.edu> wrote: > In all fairness, I do not believe that ivdep is an ICC-specific pragma. There are many compilers that support ivdep and lots of legacy (and modern) codes that benefit from it. Seems silly, to me at least, to reinvent the wheel. Hi Cameron, The history of the idvep pragma is fascinating. I did not

On Thu, May 23, 2013 at 12:02 PM, Nadav Rotem <nrotem at apple.com> wrote: > > On May 23, 2013, at 8:52 AM, "Redmond, Paul" <paul.redmond at intel.com> > wrote: > > > !0 = metadata !{ metadata !1, metadata !2 } > !1 = metadata !{ metadata !"llvm.loop.parallel" } > !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8

i have already seen usage of __builtin_nontemporal_store but i want to automate identification of non temporal loads/stores. i think i need to go for a pass. is it possiblee to detect non temporal loops without polly? On Sat, Jan 20, 2018 at 11:26 PM, Simon Pilgrim <llvm-dev at redking.me.uk> wrote: > On 20/01/2018 18:16, hameeza ahmed wrote: > > Actually i am working on vector

> On Oct 10, 2016, at 2:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > From: "Dangeti Tharun kumar via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > To: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > Cc: "Santanu Das" <cs15mtech11018 at iith.ac.in <mailto:cs15mtech11018 at

Actually i am working on vector accelerator which will perform those instructions which are non temporal. for instance if i have this loop for(i=0;i<2048;i++) a[i]=b[i]+c[i]; currently it emits following IR; %0 = getelementptr inbounds [2048 x i32], [2048 x i32]* @b, i64 0, i64 %index %1 = bitcast i32* %0 to <16 x i32>* %wide.load = load <16 x i32>, <16 x i32>* %1,

On 03/03/2013 03:34 PM, Pekka Jääskeläinen wrote: > On 03/03/2013 02:34 PM, Tobias Grosser wrote: >> Meaning they are due to an array or pointer access. > > What about loop-scope arrays? > > void foo(long *A, long b) { > long i; > > #pragma ivdep > for (i = 0; i < 100; i++) { > long t[100]; > t[0] = i + 2; >

On 03/03/2013 06:43 PM, Tobias Grosser wrote: > Very good example, indeed. Is there a formal definition of what > #pragma ivdeps means? I see two options here: In the previous discussion we could not find a proper definition for #pragma ivdep so we concluded we can treat it as a statement of "treat the loop as parallel, I do not expect any dependency checking by the compiler",

On Feb 11, 2010, at 12:50 PM, David Greene wrote: > On Thursday 11 February 2010 14:05:21 David Greene wrote: > >> Either ParseLoad and probably other instructions need to look for metadata >> explicitly or ParseOptionalCommaAlign needs to know about general metadata. >> >> My inkling is to fix ParseOptionalCommaAlign. Sound reasonable? > > Well, that's

Dear Admin, It seems that mails from our iit.ac.in domain are being marked as spam. It would be nice if something could be done about this. Best Regards Ramakrishna On Tue, Mar 24, 2015 at 1:12 AM, Aditya Kamath < adityakamath+llvmdev at gmail.com> wrote: > Hi all, > > (I received many emails that my posts were marked spam, so I am re-sending > this from another email address