Re: Re: decremnt IV patch create fails on PowerPC

["juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>]

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

Hi, Richi. Thanks for your analysis and helps.

>> 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).

I am not sure how to do that. Could you give me more informations?

I somehow understand your concern is that variable amount of IV will make
IVOPT fails. 

I have seen similar situation in LLVM (when apply variable IV,
they failed to interleave the vectorize code). I am not sure whether they
are the same reason for that.

For RVV, we not only want decrement IV style in vectorization but also
we want to apply SELECT_VL in single-rgroup which is most happen cases (LLVM also only apply get_vector_length in single vector length).

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

It seems that Power is ok with decrement IV since most cases are improved.

I think Richard may help to explain decrement IV more clearly.

Thanks


juzhe.zhong@rivai.ai
 
From: Richard Biener
Date: 2023-05-26 14:46
To: 钟居哲
CC: gcc-patches; richard.sandiford; linkw
Subject: Re: decremnt IV patch create fails on PowerPC
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.