search for: loopids

Dear LLVM community, LLVM IR has a concept of 'LoopID' [1] which is a misnomer: (a) LoopIDs are not unique: Any pass that duplicates IR will do it including its metadata (e.g. LoopVersioning) such that thereafter multiple loops are linked with the same LoopID. There is even a test case (Transforms/LoopUnroll/unroll-pragmas-disabled.ll) for multiple loops with the same LoopID. (b) LoopIDs...

Am Mi., 12. Dez. 2018 um 10:10 Uhr schrieb Finkel, Hal J. <hfinkel at anl.gov>: > > As we have seen, > > there are other reasons for loops to have identical LoopIDs. With > > patches [3,4], llvm.loop metadata can be collapsed (unlike access > > groups), thus the 'distinct' is not necessary anymore. Unfortunately, > > there is code in LLVM (and maybe elsewhere) that depends on LoopIDs' > > first item, i.e. we cannot get rid o...

...eb Finkel, Hal J. <hfinkel at anl.gov>: > > On 12/12/18 10:29 AM, Michael Kruse wrote: > > Am Mi., 12. Dez. 2018 um 10:10 Uhr schrieb Finkel, Hal J. <hfinkel at anl.gov>: > >>> As we have seen, > >>> there are other reasons for loops to have identical LoopIDs. With > >>> patches [3,4], llvm.loop metadata can be collapsed (unlike access > >>> groups), thus the 'distinct' is not necessary anymore. Unfortunately, > >>> there is code in LLVM (and maybe elsewhere) that depends on LoopIDs' > >>> firs...

Hi, I am trying to use the DependenceAnalysis pass to get the Distance vector for the innermost loop. I am in LLVM learing process. I have used the following code inside my original code to get the distance vector. It is not giving any syntax error but it is has some logical but and giving segmentation fault. void getAnalysisUsage(AnalysisUsage &AU) const { AU.setPreservesAll();

I noticed that LoopVectorizeHints::setAlreadyVectorized never deletes old "llvm.loop...." metadata. It just appends more, possibly contradicting the old metadata. E.g., after vectorization, a loop previously marked with llvm.loop.vectorize.width ends up with *two* such annotations, like this: br i1 %exitcond.1, label %for.end.loopexit.unr-lcssa, label %for.body, !llvm.loop !8

On 02/17/2013 11:15 PM, Hal Finkel wrote: > If the unroller somehow differentiates the metadata coming from different > loop iterations, then BBVectorize can use this information as well. Even > better, we could make BasicAA understand that appropriately marked loads > and stores from different iterations don't alias. Then the AA-based > dependency breaker in the scheduler could

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

----- Original Message ----- > From: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Andrew Trick" <atrick at apple.com>, "Tobias Grosser" <tobias at grosser.es>, "llvmdev at cs.uiuc.edu Dev" > <llvmdev at cs.uiuc.edu> > Sent: Monday, February 18, 2013

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

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Tobias Grosser" <tobias at grosser.es> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Sunday, February 17, 2013 2:32:25 PM > Subject: Re: [LLVMdev] Parallel Loop Metadata > > > > > > On Feb 11, 2013, at 2:58 PM,

On Feb 11, 2013, at 2:58 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 02/11/2013 10:31 PM, Nadav Rotem wrote: >> Now that we have a better understanding of the proposal for using per-instruction metadata, I think that we need to revisit the "single metedata" approach (Pekka's original suggestion). > > Following Andrew's comments we understood that

Hi llvm-dev, I recently posted an RFC about extending #pragma clang loop to the cfe-dev mailing list [1]. It proposes adding more loop transformations to Clang, defines an execution order if multiple transformations are specified and allow programmers to assign names to loops. This email is about the LLVM part of the proposal. I am happy for any feedback, especially about whether the community

----- Original Message ----- > From: "Arnold Schwaighofer" <aschwaighofer at apple.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