llvm dev - Jun 2020 - Why doesn't this loop get removed?

int f() {
    int A[100];
    for (int i = 0; i < 100; ++i)
        A[i] = i;
    return A[10];
}

Neither gcc nor clang eliminates the loop. Clang also blows up the code a bit by
unrolling the loop. Why can't this loop and the array be eliminated and the
function body turned into ret i32 10 ? Am I missing something?

/Riyaz



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200617/b68c2e7c/attachment.html>

Not sure. But I was curious enough to check where the breakpoint is -
at 61: https://godbolt.org/z/XDijBB - at 60 it does the desired thing
and optimizes down to ret of a literal.

If you're curious/want to investigate yourself you can run clang/llvm
with -mllvm -print-after-all it'll print the internal representation
after each optimization. So using that with 60 and 61 and comparing
the difference in behavior might point to at least /a/ smoking gun.

On Wed, Jun 17, 2020 at 10:54 AM Riyaz Puthiyapurayil via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> int f() {
>
>     int A[100];
>
>     for (int i = 0; i < 100; ++i)
>
>         A[i] = i;
>
>     return A[10];
>
> }
>
>
>
> Neither gcc nor clang eliminates the loop. Clang also blows up the code a
bit by unrolling the loop. Why can’t this loop and the array be eliminated and
the function body turned into ret i32 10 ? Am I missing something?
>
>
>
> /Riyaz
>
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

It might be because the LoopUnroll profitability heuristic unrolls the
loop with 60 or fewer iterations.

I'd be curious why it still stores the array up to element A[15],
although only A[10] is used.

Michael

Am Mi., 17. Juni 2020 um 13:08 Uhr schrieb David Blaikie via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> Not sure. But I was curious enough to check where the breakpoint is -
> at 61: https://godbolt.org/z/XDijBB - at 60 it does the desired thing
> and optimizes down to ret of a literal.
>
> If you're curious/want to investigate yourself you can run clang/llvm
> with -mllvm -print-after-all it'll print the internal representation
> after each optimization. So using that with 60 and 61 and comparing
> the difference in behavior might point to at least /a/ smoking gun.
>
> On Wed, Jun 17, 2020 at 10:54 AM Riyaz Puthiyapurayil via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > int f() {
> >
> >     int A[100];
> >
> >     for (int i = 0; i < 100; ++i)
> >
> >         A[i] = i;
> >
> >     return A[10];
> >
> > }
> >
> >
> >
> > Neither gcc nor clang eliminates the loop. Clang also blows up the
code a bit by unrolling the loop. Why can’t this loop and the array be
eliminated and the function body turned into ret i32 10 ? Am I missing
something?
> >
> >
> >
> > /Riyaz
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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