[llvm-dev] Why does LLVM keep some loads in the loops even after applying the O3 optimization?

[Fami H via llvm-dev]

Thank you all for your responses.

On Thu, Mar 28, 2019 at 2:59 PM David Greene <dag at cray.com> wrote:

> Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > r0 gets overwritten inside the loop (assuming dst, src, src), is ldr
> > r0, [r5] needed to initialize r0 for the loop at each iteration?
>
> Register allocation should handle that if the load is hoisted.
>
> I'm with the others.  The printf is the most likely culprit.
>
>                       -0David
>
> > On Thu, Mar 28, 2019 at 10:17 AM Fami H via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> >  Hello all,
> >
> >  I am looking at the assembly code of a loop body which is created by
> applying O3 optimization. Here it is:
> >
> >  .LBB4_19:                               @ %for.body.91
> >                                          @ =>This Inner Loop Header:
> Depth=1
> >          ldr r0, [r5]
> >          mov r1, r8
> >          add r0, r0, r7
> >          vldr s0, [r0]
> >          mov r0, r6
> >          vcvt.f64.f32 d0, s0
> >          vmov r2, r3, d0
> >          bl fprintf
> >          cmp r0, #0
> >          blt .LBB4_25
> >  @ BB#20:                                @ %for.cond.89
> >                                          @   in Loop: Header=BB4_19
> Depth=1
> >          ldr r0, .LCPI4_2
> >          add r4, r4, #1
> >          add r7, r7, #4
> >          ldr r0, [r0]
> >          cmp r4, r0
> >          blt .LBB4_19
> >
> >  There are no other basic blocks in the loop.  I am wondering why the
> first load instruction (ldr r0, [r5]) is repeatedly executed in the loop
> while the load
> >  address (r5) is never changed in the loop body. Shouldn't this
> instruction be moved out of the loop as a result of -licm flag? I mean this
> load could have been
> >  executed only once outside of the loop and the result could have been
> saved in the register and used in the loop. I'd greatly appreciate if
> anyone can tell me
> >  why this is not the case.
> >
> >  Thank you in advance,
> >  Fami
> >
> >
> >
> >  _______________________________________________
> >  LLVM Developers mailing list
> >  llvm-dev at lists.llvm.org
> >  https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190328/57d0faf2/attachment.html>