On Fri, 23 Jul 2021, guojiufu wrote:
> On 2021-06-21 20:36, Richard Biener wrote:
> > On Mon, 21 Jun 2021, guojiufu wrote:
> >
> >> On 2021-06-21 14:19, guojiufu via Gcc-patches wrote:
> >> > On 2021-06-09 19:18, guojiufu wrote:
> >> >> On 2021-06-09 17:42, guojiufu via Gcc-patches wrote:
> >> >>> On 2021-06-08 18:13, Richard Biener wrote:
> >> >>>> On Fri, 4 Jun 2021, Jiufu Guo wrote:
> >> >>>>
> >> >>> cut...
> >> > cut...
> >> >>
> >>
> >> Besides the method in the previous mails,
> >> I’m thinking of another way to split loops:
> >>
> >> foo (int *a, int *b, unsigned k, unsigned n)
> >> {
> >> while (++k != n)
> >> a[k] = b[k] + 1;
> >> }
> >>
> >> We may split it into:
> >> if (k<n)
> >> {
> >> while (++k < n) //loop1
> >> a[k] = b[k] + 1;
> >> }
> >> else
> >> {
> >> while (++k != n) //loop2
> >> a[k] = b[k] + 1;
> >> }
> >>
> >> In most cases, loop1 would be hit, the overhead of this method is only
> >> checking “if (k<n)”
> >> which would be smaller than the previous method.
> >
> > That would be your original approach of versioning the loop. I think
> > I suggested that for this scalar evolution and dataref analysis should
> > be enhanced to build up conditions under which IV evolutions are
> > affine (non-wrapping) and the versioning code in actual transforms
> > should then do the appropriate versioning (like the vectorizer already
> > does for niter analysis ->assumptions for example).
>
> Hi Richi,
>
> Thanks for your suggestion!
>
> The original idea was trying to cover cases like multi-exit loops, while it
> seems not benefited too much. The method you said would help for common
> cases.
>
> I'm thinking of the methods to implement this:
> During scev analyzing, add more possible wrap checking (especially for
> unsigned)
> for convert_affine_scev/scev_probably_wraps_p/chrec_convert_1; introducing
> no_wrap_assumption for the conditions of no-wrapping on given chrec/iv.
> And using this assumption in simple_iv_with_niters/dr_analyze_innermost.
>
> One question is, where is the best place to add this assumption?
> Is it a flexible idea to add no_wrap_assumption to affine_iv/loop, and
> set the assumption when scev checks wrap?
I'm not sure what you exactly mean here. I was thinking of
making analyze_scalar_evolution return more than a plain
tree, for example by providing an alternate (optional) output,
for example a pointer to some new scev_info that could initially
be just
struct scev_info {
tree assumptions;
};
when analyze_scalar_evolution recurses there are certain points
it can end up returning chrec_dont_know. If we passed in the
alternate output there might be the possibility to add
to the assumption to make the result well-defined (and yes,
this extends to chrec_fold_* routines, mostly chrec_convert
I think). Handled cases could be added piecewise, just passing
down the scev_info pointer will be intrusive initially.
For simple_iv there's already a struct we could add 'assumptions'
to (and maybe a flag to the API whether assumptions are allowed).
For DR analysis the same could be done.
Richard.
> Thanks for your suggestions!
>
> BR.
> Jiufu
>
>
> >
> > Richard.
> >
> cut....
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
