https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #5)
> Another example:
>
> #include <time.h>
> void f(){
> const int n=1<<14;
> double a[n];
> double b[n];
> double c[n];
> __builtin_memset(a,0,n);
> __builtin_memset(b,0,n);
> __builtin_memset(c,0,n);
> for(int i=0;i<n;++i)
> c[i]=a[i]+b[i];
> time(0);
> }
I guess you meant (notice the bogus memset size above):
#include <time.h>
void f(){
const int n=1<<14;
double a[n];
double b[n];
double c[n];
__builtin_memset(a,0,n*sizeof(double));
__builtin_memset(b,0,n*sizeof(double));
__builtin_memset(c,0,n*sizeof(double));
for(int i=0;i<n;++i)
c[i]=a[i]+b[i];
time(0)
}
> If I make n a constant (using #define), DCE knows that c is not
> ref_may_be_aliased (that test could probably be weakened) and removes almost
> everything. We don't replace alloca_with_align with an array because the
> size is larger than 256 (with a more limited scope the limit would even be
> 25...). DSE is likely confused by the loop. And PRE and others don't know
> that a[i] is always 0. (llvm removes everything but the final call)
