https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jiangning Liu from comment #3)
> It is a stupid test, but it is simplified from a real application.
>
> To solve even more complicated scenario, this simple case needs to be
> addressed first.
>
> If we change the case to be as below,
>
> int f(void)
> {
> int i, a[1024], s=0;
>
> for (i=0; i<1024; i++)
> a[i] = 5;
>
> for (i=0; i<37; i++)
> s += a[i];
> return s;
> }
>
> the loop peeling will not work, but compiler should still know the store to
> elements with index >= 37 can all be eliminated. Can any framework in GCC
> solve this problem?
No, not when faced with loops. If both loops were completely unrolled then
DSE would do this job but as it stands DSE doesn't know how to adjust
a loops iteration space to elide dead stores. In the above case splitting
the first loop into two so that the first iterates [0, 37[ and the second
[37, 1024[ would make the problem easier for DSE. We could then also
fuse the loops, eliding a completely. So I guess loop fusion might be
the actual transform we're looking after (which for enablement needs the
loop splitting).
I suppose the "real" application doesn't iniitalize a[i] to all 5? But
the first loop is actually some kind of initialization?
