On Tue, 30 May 2023, Kewen.Lin wrote:
> on 2023/5/30 17:26, juzhe.zh...@rivai.ai wrote:
> > 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 guess no, with this condition any targets without SELECT_VL are unable
> to leverage the new decrement scheme for lengths, as your reply in PR109971
> you didn't meant to disable it. IIUC, what Richi suggested is to introduce
> one new IV just like the previous one which has non-variable step, then it's
> SCEV-ed and some analysis based on it can do a good job.
No, I said the current scheme does sth along
do {
remain -= MIN (vf, remain);
} while (remain != 0);
and I suggest to instead do
do {
old_remain = remain;
len = MIN (vf, remain);
remain -= vf;
} while (old_remain >= vf);
basically since only the last iteration will have len < vf we can
ignore that remain -= vf will underflow there if we appropriately
rewrite the exit test to use the pre-decrement value.
> Since this is mainly for targets without SELECT_VL capability, I can follow
> up this if you don't mind.
>
> BR,
> Kewen
>
--
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)
