Re: decremnt IV patch create fails on PowerPC

[Richard Biener <rguenther@suse.de>]

On Fri, 26 May 2023, ??? wrote:

> Yesterday's patch has been approved (decremnt IV support):
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619663.html 
> 
> However, it creates fails on PowerPC:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109971 
> 
> I am really sorry for causing inconvinience.
> 
> I wonder as we disccussed:
> +  /* If we're vectorizing a loop that uses length "controls" and
> +     can iterate more than once, we apply decrementing IV approach
> +     in loop control.  */
> +  if (LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
> +      && !LOOP_VINFO_LENS (loop_vinfo).is_empty ()
> +      && LOOP_VINFO_PARTIAL_LOAD_STORE_BIAS (loop_vinfo) == 0
> +      && !(LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo)
> +	   && known_le (LOOP_VINFO_INT_NITERS (loop_vinfo),
> +			LOOP_VINFO_VECT_FACTOR (loop_vinfo))))
> +    LOOP_VINFO_USING_DECREMENTING_IV_P (loop_vinfo) = true;
> 
> This conditions can not disable decrement IV on PowerPC.
> Should I add a target hook for it?

No.  I've put some analysis in the PR.  To me the question is
why (without that SELECT_VL case) we need a decrementing IV
_for the loop control_?  We could simply retain the original
incrementing IV for loop control and add the decrementing
IV for computing LEN in addition to that and leave IVOPTs
sorting out to eventually merge them (or not).

Alternatively avoid the variable decrement as I wrote in the
PR and do the exit test based on the previous IV value.

But as said all this won't work for the SELECT_VL case, but
then it's availability is something to key off rather than a
new target hook?

> The patch I can only do bootstrap and regression on X86.
> I didn't have an environment to test PowerPC. I am really sorry.

You can do some testing with a cross compiler, alternatively
there are powerpc machines in the GCC compile farm.

Richard.