Re: Question on tree LIM

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
> I am investigating one degradation related to SPEC2017 exchange2_r,
> with loop vectorization on at -O2, it degraded by 6%.  By some
> isolation, I found it isn't directly caused by vectorization itself,
> but exposed by vectorization, some stuffs for vectorization
> condition checks are hoisted out and they increase the register
> pressure, finally results in more spillings than before.  If I simply
> disable tree lim4, I can see the gap becomes smaller (just 40%+ of
> the original), if further disable rtl lim, it just becomes to 30% of
> the original.  It seems to indicate there is some room to improve in
> both LIMs.
>
> By quick scanning in tree LIM, I noticed that there seems no any
> considerations on register pressure, it looked intentional? I am
> wondering what's the design philosophy behind it?  Is it because that
> it's hard to model register pressure well here?  If so, it seems to
> put the burden onto late RA, which needs to have a good
> rematerialization support.

Yes, it is "intentional" in that doing any kind of prioritization based
on register pressure is hard on the GIMPLE level since most
high-level transforms try to expose followup transforms which you'd
somehow have to anticipate.  Note that LIMs "cost model" (if you can
call it such...) is too simplistic to be a good base to decide which
10 of the 20 candidates you want to move (and I've repeatedly pondered
to remove it completely).

As to putting the burden on RA - yes, that's one possibility.  The other
possibility is to use the register-pressure aware scheduler, though not
sure if that will ever move things into loop bodies.

> btw, the example loop is at line 1150 from src exchange2.fppized.f90
>
>    1150 block(rnext:9, 7, i7) = block(rnext:9, 7, i7) + 10
>
> The extra hoisted statements after the vectorization on this loop
> (cheap cost model btw) are:
>
>     _686 = (integer(kind=8)) rnext_679;
>     _1111 = (sizetype) _19;
>     _1112 = _1111 * 12;
>     _1927 = _1112 + 12;
>   * _1895 = _1927 - _2650;
>     _1113 = (unsigned long) rnext_679;
>   * niters.6220_1128 = 10 - _1113;
>   * _1021 = 9 - _1113;
>   * bnd.6221_940 = niters.6220_1128 >> 2;
>   * niters_vector_mult_vf.6222_939 = niters.6220_1128 & 18446744073709551612;
>     _144 = niters_vector_mult_vf.6222_939 + _1113;
>     tmp.6223_934 = (integer(kind=8)) _144;
>     S.823_1004 = _1021 <= 2 ? _686 : tmp.6223_934;
>   * ivtmp.6410_289 = (unsigned long) S.823_1004;
>
> PS: * indicates the one has a long live interval.

Note for the vectorizer generated conditions there's quite some room for
improvements to reduce the amount of semi-redundant computations.  I've
pointed out some to Andre, in particular suggesting to maintain a single
"remaining scalar iterations" IV across all the checks to avoid keeping
'niters' live and doing all the above masking & shifting repeatedly before
the prologue/main/vectorized epilogue/epilogue loops.  Not sure how far
he got with that idea.

Richard.

>
> BR,
> Kewen