https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105175

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmalcolm at gcc dot gnu.org,
                   |                            |msebor at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
@item -Wvector-operation-performance
@opindex Wvector-operation-performance
@opindex Wno-vector-operation-performance
Warn if vector operation is not implemented via SIMD capabilities of the
architecture.  Mainly useful for the performance tuning.
Vector operation can be implemented @code{piecewise}, which means that the
scalar operation is performed on every vector element;
@code{in parallel}, which means that the vector operation is implemented
using scalars of wider type, which normally is more performance efficient;
and @code{as a single scalar}, which means that vector fits into a
scalar type.

--

So the point is the vector lowering pass cannot distinguish people writing

typedef int v2si __attribute__((vector_size(8)));

v2si a, b;
void foo()
{
   a &= b;
}

and the vectorizer producing such code.  So technically the diagnostic is
correct but it was the vectorizer producing the operation.

So a proper way would be to suppress OPT_Wvector_operation_performance for
the vectorizer generated stmt.  Unfortunately

          if (using_emulated_vectors_p)
            suppress_warning (new_stmt, OPT_Wvector_operation_performance);

will not magically make

      warning_at (loc, OPT_Wvector_operation_performance,
                  "vector operation will be expanded with a "
                  "single scalar operation");

not warn.  suppress_warning_at returns true, and supp is true as well
(that parameter is not documented as far as I can see).  So we need to
guard all the warning_at with stmt-based warning_suppressed_p and
there's no warning_at overload with a gimple * as location that would
automagically do that it seems?  There is one with rich_location * but
AFAIK that doesn't cover gimple * or tree.

I'm testing a patch that is IMHO too verbose (adjusting all warning_at
in tree-vect-generic.cc).

Reply via email to