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.
