[Bug tree-optimization/98176] Loop invariant memory could not be hoisted when nonpure_call in loop body

["wwwhhhyyy333 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.