On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richard.
>
> >> I don't object though. It just feels like we're giving up easily.
> >> And that's a bit frustrating, since this potential problem was flagged
> >> ahead of time.
>
> I can take a look at it. Would you mind giving me some hints?
> Should I do this in which PASS ? "ivopts" PASS?
> Is that right that we can enhance analysis when we see the statement as
> follows:
> remain = remain - step and step is coming from a MIN_EXPR (remain, vf).
> Then what we need to do?
The key is that we have
# iv = PHI <initial, iv'>
step = MIN (iv, invariant);
iv' = iv - step;
if (iv' != 0)
continue;
in that case for the purpose of niter analysis we can ignore
the MIN expression and use 'invariant' as step (whether constant
or not). Of course it only works for unsigned 'step'.
niter analysis uses simple_iv () but that necessarily fails here
so one idea would be to enhance simple_iv when passed a special
flag. Another idea is to add to the set of patterns niter analysis
already has to compute niters resolving to popcount and friends
and pattern match the above (I'd start with that to see which other
passes / analyses besides niter analysis need improvement).
number_of_iterations_exit_assumptions does
if (!simple_iv_with_niters (loop, loop_containing_stmt (stmt),
op0, &iv0, safe ? &iv0_niters : NULL,
false))
return number_of_iterations_bitcount (loop, exit, code, niter);
so I'd add that to the set of matchers in number_of_iterations_bitcount
(and maybe rename that to number_of_iterations_pattern).
Richard.
> Thanks.
>
>
> juzhe.zh...@rivai.ai
>
> From: Richard Sandiford
> Date: 2023-05-31 15:28
> To: Richard Biener
> CC: juzhe.zhong\@rivai.ai; gcc-patches; linkw
> Subject: Re: [PATCH] VECT: Change flow of decrement IV
> Richard Biener <rguent...@suse.de> writes:
> > On Wed, 31 May 2023, juzhe.zh...@rivai.ai wrote:
> >
> >> Hi?all. I have posted my several investigations:
> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620101.html
> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620105.html
> >> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620108.html
> >>
> >> Turns out when "niters is a constant value and vf is a constant value"
> >> This patch can allow SCEV/IVOPTS optimize a lot for RVV too (Take tesecase
> >> from IBM's testsuite for example) and I think this patch can fix IBM's
> >> cunroll issue.
> >> Even though it will produce a 'mv' instruction in some ohter cases for
> >> RVV, I think Gain > Pain overal.
> >>
> >> Actually, for current flow:
> >>
> >> step = MIN ()
> >> ...
> >> remain = remain - step.
> >>
> >> I don't know how difficult to extend SCEV/IVOPTS to fix this issue.
> >> So, could you make a decision for this patch?
> >>
> >> I wonder whether we should apply the approach of this patch (the codes can
> >> be refined after well reviewed) or
> >> we should extend SCEV/IVOPTS ?
> >
> > I don't think we can do anything in SCEV for this which means we'd
> > need to special-case this in niter analysis, in IVOPTs and any other
> > passes that might be affected (and not fixed by handling it in niter
> > analysis). While improving niter analysis would be good (the user
> > could write this pattern as well) I do not have time to try
> > implementing that (I have no idea how ugly or robust it is going to be).
> >
> > So I think we should patch this up in the vectorizer itself like with
> > your patch. I'm going to wait for Richards input though since he
> > seems to disagree.
>
> I think my main disagreement is that the IV phi can be analysed
> as a SCEV with sufficient work (realising that the MIN result is
> always VF when the latch is executed). That SCEV might be useful
> ?as is? for things like IVOPTS, without specific work in those passes.
> (Although perhaps not too useful, since most other IVs will be upcounting.)
>
> I don't object though. It just feels like we're giving up easily.
> And that's a bit frustrating, since this potential problem was flagged
> ahead of time.
>
> > Note with SELECT_VL all bets will be off since as I understand the
> > value it gives can vary from iteration to iteration (but we know
> > a lower and maybe an upper bound?)
>
> Right. All IVs will have a variable step for SELECT_VL.
>
> Thanks,
> 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)
