Re: Question on tree LIM

["Kewen.Lin" <linkw@linux.ibm.com>]

Hi Richard,

on 2021/7/2 下午4:07, Richard Biener wrote:
> 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).
> 

Thanks for the explanation!  Do you really want to remove it completely
rather than just improve it with a better one?  :-\

Here there are some PRs (PR96825, PR98782) related to exchange2_r which
seems to suffer from high register pressure and bad spillings.  Not sure
whether they are also somehow related to the pressure given from LIM, but
the trigger is commit
1118a3ff9d3ad6a64bba25dc01e7703325e23d92 which adjusts prediction
frequency, maybe it's worth to re-visiting this idea about considering
BB frequency in LIM cost model:
https://gcc.gnu.org/pipermail/gcc/2014-November/215551.html

> 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.
> 

Brandly new idea!  IIUC it requires a global scheduler, not sure how well
GCC global scheduler performs, generally speaking the register-pressure
aware scheduler will prefer the insn which has more deads (for that
intensive regclass), for this problem the modeling seems a bit different,
it has to care about total interference numbers between two "equivalent"
blocks (src/dest), not sure if it's easier to do than rematerialization.

>> 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.
> 

Great, it definitely helps to mitigate this problem.  Thanks for the information.


BR,
Kewen