similar to: [LLVMdev] [LV] possible `vector.memcheck` regression when using `llvm.loop` and `llvm.mem.parallel_loop_access`

Adam, Please find the attached test case (run with ToT opt -O3). As you can see, `y_body` successfully is vectorized, though %33 and %46 are deemed MayAlias despite their exclusive use in loads ands stores marked with `llvm.mem.parallel_loop_access`. Many Thanks, Josh On Thu, Mar 19, 2015 at 12:55 PM, Adam Nemet <anemet at apple.com> wrote: > > > On Mar 19, 2015, at 9:43 AM,

Using LLVM ToT and Hal's helpful slide deck [1], I've been trying to use `llvm.assume` to communicate pointer alignment guarantees to vector load and store instructions. For example, in [2] %5 and %9 are guaranteed to be 32-byte aligned. However, if I run this IR through `opt -O3 -datalayout -S`, the vectorized loads and stores are still 1-byte aligned [3]. What's going wrong? Do I

I'm building a simple R extension around a CUDA-enabled dynamic library, and I want to run the whole package with cuda-memcheck for debugging purposes. I can run it just fine with Valgrind: $ R --no-save -d valgrind < test.R However, if I try the same thing with cuda-memcheck, $ R --no-save -d cuda-memcheck < test.R I get: *** Further command line arguments ('--no-save ')

Julia and OpenMP 4.0 have features where the user can bless a loop as having no memory dependences that prevent vectorization, thus enabling vectorization of loops not amenable to compile-time or run-time dependence analysis. LLVM currently has no metadata to express such, as explained further below. I'd like to propose new metadata that enables front-ends to tell the vectorizer that

Here's an attempt to nail down the annotation semantics with support for respecting forward lexical dependences. Each load, store, call, or invoke instruction can be labeled with !llvm.mem.vector_loop_access, which has two operands: * The first operand is an integer denoting lexical position. The positions need not be consecutive, and may contain duplicates. * The second operand is the

I have ran under valgrind memcheck the process using libLLVM-2.9.so (rev.126022) and got several errors: ==24227== Invalid read of size 1 ==24227== at 0x40274C9: memcpy (mc_replace_strmem.c:497) ==24227== by 0x40D5B84: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in

> 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

On 05/23/2013 06:52 PM, Redmond, Paul wrote: > I'm not even sure you would need the llvm.loop.parallel anymore since the > vectorizer could just look to see if the loop id on a parallel_loop_access > matches the loop id of the loop being vectorized. > > Does this make any sense? Yes. However, I think you still need use the self-referencing metadata trick or similar to make the

It's a problem in the OpenMP specification. The authors (including some from Intel) intended that the OpenMP simd construct assert no lexically backward dependences exist, but as you say, it's not obvious from the spec. One of our OpenMP community members is going to bring up the ambiguity with the OpenMP committee. - Arch -----Original Message----- From: Humphreys, Jonathan

Hello all, Thanks for the comments. Attached is a new version with Tobias' and Sebastian's (final?) comments addressed. Any further comments are appreciated. Nadav suggested a request for comments in llvmdev before committing it. In order to describe the current idea of the parallel loop metadata, I think it's easiest to just copy-paste the documentation I wrote for this patch so

Hi, I've been working on clang codegen for #pragma ivdep and creating the llvm.mem.parallel_loop_access metadata seems quite difficult. The main problem is that there are so many places where loads and stores are created and all of them need to be changed when emitting a parallel loop. Note that creating llvm.loop.parallel is not a problem. One option is to modify IRBuilder to enable

Hi Hal, On 2013-02-28, at 9:33 PM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Paul Redmond" <paul.redmond at intel.com> >> To: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> >> Sent: Thursday, February 28, 2013 1:30:57 PM >> Subject: [LLVMdev] parallel loop metadata simplification >> >> Hi, >>

On 2013-05-23, at 10:37 AM, Arnold Schwaighofer wrote: > > On May 23, 2013, at 9:15 AM, Renato Golin <renato.golin at linaro.org> wrote: > >> On 23 May 2013 14:52, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: >> I would like us to grow a few annotations, among others, one to force vectorization irrespective whether the loop vectorizer thinks it is

----- 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

On 02/19/2013 05:51 PM, Hal Finkel wrote: > Understood. If you have some time, it seems that there are several sub-tasks: > > - Update the language reference Document the additional optional iteration id argument to llvm.mem.parallel_loop_access? I'll do this. > - Update the loop vectorizer (to update the metadata when it unrolls) > - Update the regular unroller

On 2013-03-01, at 11:35 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Paul Redmond" <paul.redmond at intel.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> >> Sent: Friday, March 1, 2013 10:06:51 AM >> Subject: Re: [LLVMdev] parallel loop

I propose that we change the first paragraph of http://llvm.org/docs/LangRef.html#llvm-mem-parallel-loop-access-metadata: --- For a loop to be parallel, in addition to using the llvm.loop metadata to mark the loop latch branch instruction, also all of the memory accessing instructions in the loop body need to be marked with the llvm.mem.parallel_loop_access metadata. If there is at least one

Hi, I was wondering how it was possible to access the actual cluster exemplars from the APResult class. Currently it only spits it out onto the terminal if you type the object but there is no other way to see which one is the examplar. Would appreciate any help. Thanks, Sachin [[alternative HTML version deleted]]

OK, I updated the text to LangRef in r209507 after some editing. On 05/11/2014 12:36 PM, Pekka Jääskeläinen wrote: > Hi, > > This looks good to me except that the first sentence > could already include "that refer to the same loop" or > similar. > > I could imagine that e.g. loop invariant code motion, > if applied to a parallel loop could hoist code out of >

----- Original Message ----- > From: "Paul Redmond" <paul.redmond at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 1, 2013 10:06:51 AM > Subject: Re: [LLVMdev] parallel loop metadata simplification > > Hi Hal, > > On 2013-02-28, at 9:33