search for: vector_loop_access

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 same as the first operand to llvm.mem.parallel_loop_access. It's second so that it can be omitted - see mentio...

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "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

> 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

...ructions in lexical order. If the latter is the case, perhaps we could have a helper routine that, given the IR early and in lexical order, finishes the annotation work? It seems that we need metadata on each memory access, distinct from llvm.mem.parallel_loop_access. Say something like llvm.mem.vector_loop_access that includes relative lexical position as a third operand? Second operand could point back to the metadata with the minimum loop-carried distance, which in turn could point back to the loop id. - Arch ------------------------------ Message: 15 Date: Wed, 20 Aug 2014 09:18:14 -0700 From: Jo...

...r. If the latter > is the case, perhaps we could have a helper routine that, given the IR early > and in lexical order, finishes the annotation work? > > It seems that we need metadata on each memory access, distinct from > llvm.mem.parallel_loop_access. Say something like llvm.mem.vector_loop_access > that includes relative lexical position as a third operand? Second operand > could point back to the metadata with the minimum loop-carried distance, > which in turn could point back to the loop id. > > - Arch > > > > > > ------------------------------ > >...

...t; is the case, perhaps we could have a helper routine that, given the IR early > > and in lexical order, finishes the annotation work? > > > > It seems that we need metadata on each memory access, distinct from > > llvm.mem.parallel_loop_access. Say something like llvm.mem.vector_loop_access > > that includes relative lexical position as a third operand? Second operand > > could point back to the metadata with the minimum loop-carried distance, > > which in turn could point back to the loop id. > > > > - Arch > > > > > > > > > &...

...aps we could have a helper routine that, given the IR early > > > and in lexical order, finishes the annotation work? > > > > > > It seems that we need metadata on each memory access, distinct from > > > llvm.mem.parallel_loop_access. Say something like llvm.mem.vector_loop_access > > > that includes relative lexical position as a third operand? Second operand > > > could point back to the metadata with the minimum loop-carried distance, > > > which in turn could point back to the loop id. > > > > > > - Arch > > > > &...