https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98176
--- Comment #4 from Hongyu Wang <wwwhhhyyy333 at gmail dot com> ---
(In reply to Richard Biener from comment #3)
> I see ret[0] has store-motion applied. You don't see it vectorized
> because GCC doesn't know how to vectorize sincos (or cexpi which is
> what it lowers it to).
I doubt so, after manually store motion
#include <cmath>
float foo(
int *x,
int n,
float tx
)
{
float ret[n];
float tmp;
#pragma omp simd
for (int i = 0; i < n; i++)
{
float s, c;
sincosf( tx * x[i] , &s, &c );
tmp += s*c;
}
ret[0] += tmp;
return ret[0];
}
with -Ofast -fopenmp-simd -std=c++11 it could be vectorized to call
_ZGVbN4vvv_sincosf
ret[0] is moved for sinf() case, but not sincosf() with above options.
>
> If you replace sincosf with a random call then you'll hit the issue
> that LIMs dependence analysis doesn't handle it at all since it cannot
> represent it. That will block further optimization in the loop.
>
> That can possibly be improved.
>
So could LIMs dependence analysis handle known library function and just
analyze their memory parameter? Random call may have unknown behavior.
> > if (nonpure_call_p (stmt))
> > {
> > maybe_never = true;
> > outermost = NULL;
> > }
> >
> > So no store-motion chance for any future statement in such block.
>
> That's another issue - the call may not return. Here the granularity
> is per BB and thus loads/stores in the same BB are not considered for
> sinking.
>
IMHO the condition may be too strict for known library calls.
