llvm dev - Feb 2013 - [LLVMdev] loop metdata instruction

Hi,

On 2013-02-25, at 5:11 PM, Krzysztof Parzyszek wrote:
> On 2/25/2013 2:08 PM, Redmond, Paul wrote:
>> 
>> I've been looking through past threads looking for an answer to why
the loop metadata is attached to the loop latch branch. What is the reason for
putting the metadata inside the loop rather than outside (for example on the
branch into the loop header.)
> 
> Latch is a branch to the header.  What branch in particular do you have in
mind?
On the branch into the loop:

define void @foo(i32 %n, float* %a, float* %b) #0 {
entry:
  [...]
  br label %for.cond, !llvm.loop.parallel !0
for.cond:                                         ; preds = %for.inc, %entry
  [...]
  br i1 %cmp, label %for.body, label %for.end
for.body:                                         ; preds = %for.cond
  [...]
  br label %for.inc
for.inc:                                          ; preds = %for.body
  [...]
  br label %for.cond
for.end:                                          ; preds = %for.cond
  ret void
}

Which optimizes to the following (with a small change to LoopRotation.cpp)

define void @foo(i32 %n, float* nocapture %a, float* nocapture %b) #0 {
entry:
  %cmp6 = icmp sgt i32 %n, 0
  br i1 %cmp6, label %for.body, label %for.end, !llvm.loop.parallel !0

for.body:                                         ; preds = %entry, %for.body
  %indvars.iv = phi i64 [ %indvars.iv.next, %for.body ], [ 0, %entry ]
  %arrayidx = getelementptr inbounds float* %b, i64 %indvars.iv
  %0 = load float* %arrayidx, align 4, !tbaa !1
  %arrayidx2 = getelementptr inbounds float* %a, i64 %indvars.iv
  store float %0, float* %arrayidx2, align 4, !tbaa !1
  %indvars.iv.next = add i64 %indvars.iv, 1
  %lftr.wideiv = trunc i64 %indvars.iv.next to i32
  %exitcond = icmp eq i32 %lftr.wideiv, %n
  br i1 %exitcond, label %for.end, label %for.body

for.end:                                          ; preds = %for.body, %entry
  ret void
}

paul
> 
> Loop latch identifies the loop.  Loops with multiple latches are not very
amenable to optimizations.
> 
> -Krzysztof
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 2/25/2013 4:50 PM, Redmond, Paul wrote:
>
> On the branch into the loop:
Well... In this case the metadata is not on the latch.  I guess this is 
because the initial loop structure is this questionable 
jump-to-cond-then-back scheme.  I agree---this doesn't look right.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

Hi,

On 2013-02-25 8:22 PM, "Krzysztof Parzyszek" <kparzysz at
codeaurora.org>
wrote:
>On 2/25/2013 4:50 PM, Redmond, Paul wrote:
>>
>> On the branch into the loop:
>
>Well... In this case the metadata is not on the latch.  I guess this is
>because the initial loop structure is this questionable
>jump-to-cond-then-back scheme.  I agree---this doesn't look right.
This loop structure is not questionable--it's what clang generates for a
for loop..

I'm suggesting this as a possible alternative to the loop latch approach.
Please re-read my original email.

paul
>
>-Krzysztof
>
>-- 
>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>hosted by The Linux Foundation