https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111401
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Robin Dapp from comment #6) > Created attachment 55902 [details] > 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? Yes, if the rounding mode isn't known there isn't a working neutral element. > neutral_op_for_reduction could return a -0 for PLUS if we honor it for that > type. Or is that too intrusive? I suppose that could work, but we need to check that we're not using this for the initial value. > 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. Yeah, but then a fold-left reduction wasn't necessary in the first place? We should avoid that (it's slow even when the target supports it) when possible. > 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.
