search for: loopid

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

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

...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' > >>> fir...

...gt;(); AU.addPreserved<MemoryDependenceAnalysis>(); } In runOnFunction I have used dependence = &getAnalysis<DependenceAnalysis>(); if(L->getSubLoops().size()==0) { Dependence* dependence; const SCEV* scev = dependence->getDistance(loopID); .... ................ ............. } loopID is and unsigned int variable which I have increased after each time after doing some other operations on loop like printing the basic block of each loop. Is this the correct way to do it. Any exam...

...uot;llvm.loop.vectorize.width", i32 1} !7 = metadata !{metadata !"llvm.loop.interleave.count", i32 1} !8 = metadata !{metadata !8, metadata !9, metadata !6, metadata !7} !9 = metadata !{metadata !"llvm.loop.vectorize.width", i32 4} !6 and !9 are in the list for loopID !8 and they specify conflicting widths. Is this a bug, or is there a deliberate convention that if there are multiple llvm.loop.vectorize.width annotations, only the last one counts? - Arch D. Robison Intel Corporation

...ormation" to the memory accesses. In this case it would communicate that the mem access belongs (or belonged, if fully unrolled) to a loop and it can alias only with the accesses from the same iteration, or with accesses without the metadata. Something like: llvm.mem.parallel_loop_iteration [loopid] [iteration_id_integer] This can help the "pairing" of the BBVectorizer: it can try to pair with the different iterations first. The ParallelLoopIterationAA can look at this metadata and if the other instruction has also a parallel_loop_iteration MD that points to the same loopid (the se...

...irst 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 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, %e...

...s case it would communicate that the mem > access > belongs (or belonged, if fully unrolled) to a loop and it can alias > only with > the accesses from the same iteration, or with accesses without the > metadata. > > Something like: > > llvm.mem.parallel_loop_iteration [loopid] [iteration_id_integer] Why don't we just add an optional iteration id to !llvm.mem.parallel_loop_access? > > This can help the "pairing" of the BBVectorizer: it can try to pair > with > the different iterations first. This makes sense. > The ParallelLoopIterationA...

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

...ond, a pass must carry-out all transformations. Regarding the first part, I suggest storing the loop transformations in a metadata node of the parent function, e.g.: define func() !looptransform !3 [...] br i1 %cond, label %loopheader, ... !loop !1 !1 = distinct !{ !4, !2 } ; LoopID !2 = {"llvm.loop.id", "myloop"} ; Loop name Only the loop id remains a property of the loop. The transformations are stored in the !looptransform metadata node: !3 = { !3, !4, ... } ; Ordered list of loop transformations !4 = {"llvm.loop.reverse, !1, "rev...

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