[Bug middle-end/111401] Middle-end: Missed optimization of MASK_LEN_FOLD_LEFT_PLUS

["rdapp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #6 from Robin Dapp <rdapp at gcc dot gnu.org> ---
Created attachment 55902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55902&action=edit
Tentative

You're referring to the case where we have init = -0.0, the condition is false
and we end up wrongly doing -0.0 + 0.0 = 0.0?
I suppose -0.0 the proper neutral element for PLUS (and WIDEN_SUM?) when
honoring signed zeros?  And 0.0 for MINUS?  Doesn't that also depend on the
rounding mode?

neutral_op_for_reduction could return a -0 for PLUS if we honor it for that
type.  Or is that too intrusive?

Guess I should add a test case for that as well.

Another thing is that swapping operands is not as easy with COND_ADD because
the addition would be in the else.  I'd punt for that case for now.

Next problem - might be a mistake on my side.  For avx512 we create a COND_ADD
but the respective MASK_FOLD_LEFT_PLUS is not available, causing us to create
numerous vec_extracts as fallback that increase the cost until we don't
vectorize anymore.

Therefore I added a
vectorized_internal_fn_supported_p (IFN_FOLD_LEFT_PLUS, TREE_TYPE (lhs)).
SLP paths and ncopies != 1 are excluded as well.  Not really happy with how the
patch looks now but at least the testsuites on aarch and x86 pass.