https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80844
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> If OMP SIMD always zeros the vector then it could also emit the maybe easier
> to optimize
>
> WITH_SIZE_EXPR<_3, D.2841> = {};
It doesn't always zero, it can be pretty arbitrary. For the default reductions
on integral/floating point types it does zero for +/-/|/^/|| reductions, but
e.g. 1 for */&&, or ~0 for &, or maximum or minimum for min or max. For user
defined reductions it can be whatever the user requests, constructor for some
class type, function call, set to arbitrary value etc.
For other privatization clauses it is again something different (uninitialized
for private/lastprivate, some other var + some bias for linear, ...).
And then after the simd loop there is again a reduction or something similar,
but again can be quite complex in the general case. If it helps, we could mark
the pre-simd and post-simd loops somehow in the loop structure or something,
but the actual work needs to be done later, especially after inlining,
including the vectorizer and other passes.
E.g. for the typical reduction where the vectorizer computes the "simd array"
in a vector temporary (or collection of them), it would be nice if we were able
to pattern recognize simple cases and turn those into vector reduction
patterns.
