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

Ryan Taylor via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 28 07:35:25 PDT 2019


r0 gets overwritten inside the loop (assuming dst, src, src), is ldr r0,
[r5] needed to initialize r0 for the loop at each iteration?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190328/1ef9209e/attachment.html>


More information about the llvm-dev mailing list