[llvm-dev] Why doesn't this loop get removed?

[Michael Kruse via 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