Ok. It seems that for this conditions:
+ /* 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; I should add direct_supportted_p (SELECT_VL...) to this is that right? I have send SELECT_VL patch. I will add this in next SELECT_VL patch. Let's wait Richard's more comments. Thanks. juzhe.zh...@rivai.ai From: Richard Biener Date: 2023-05-30 17:22 To: juzhe.zh...@rivai.ai CC: gcc-patches; richard.sandiford; linkw Subject: Re: Re: decremnt IV patch create fails on PowerPC On Fri, 26 May 2023, juzhe.zh...@rivai.ai wrote: > 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. Well, but Power never will have SELECT_VL so at least for !SELECT_VL targets you should avoid having an IV with variable decrement. As I said it should be easy to rewrite decrement IV to use a constant increment (when not using SELECT_VL) and testing the pre-decrement value in the exit test. Richard. > I think Richard may help to explain decrement IV more clearly. > > Thanks > > > juzhe.zh...@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. > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
