RE: [PATCH] Add a heuristic for eliminate redundant load and store in inline pass.

["Cui, Lili" <lili.cui@intel.com>]

Hi Honza,
Gentle ping  https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597891.html

Thanks,
Lili.

> -----Original Message-----
> From: Gcc-patches <gcc-patches-bounces+lili.cui=intel.com@gcc.gnu.org> On
> Behalf Of Cui, Lili via Gcc-patches
> Sent: Sunday, July 10, 2022 10:05 PM
> To: Jan Hubicka <hubicka@kam.mff.cuni.cz>
> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; Liu, Hongtao
> <hongtao.liu@intel.com>; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Add a heuristic for eliminate redundant load and store
> in inline pass.
> 
> 
> > -----Original Message-----
> > From: Jan Hubicka <hubicka@kam.mff.cuni.cz> This is interesting idea.
> > Basically we want to guess if inlining will
> > make SRA and or strore->load propagation possible.   I think the
> > solution using INLINE_HINT may be bit too trigger happy, since it is
> > very common that this happens and with -O3 the hints are taken quite
> sriously.
> >
> > We already have mechanism to predict this situaiton by simply
> > expeciting that stores to addresses pointed to by function parameter
> > will be eliminated by 50%.  See eliminated_by_inlining_prob.
> >
> > I was thinking that we may combine it with a knowledge that the
> > parameter points to caller local memory (which is done by llvm's
> > heuristics) which can be added to IPA predicates.
> >
> > The idea of checking that the actual sotre in question is paired with
> > load at caller side is bit harder: one needs to invent representation
> > for such conditions.  So I wonder how much extra help we need for
> > critical inlning to happen at imagemagics?
> 
> Hi Honza,
> 
> Really appreciate for the feedback. I found that eliminated_by_inlining_prob
> does eliminated  the stmt 50% of the time, but the gap is still big.
> SRA cannot split callee's parameter for "Do not decompose non-BLKmode
> parameters in a way that would create a BLKmode parameter. Especially for
> pass-by-reference (hence, pointer type parameters), it's not worth it."
> 
> Critical inline function information
> 
> Caller:    GetVirtualPixelsFromNexus
> size:        541
> time:      484.08
> e->freq: 0.83
> 
> Callee:    SetPixelCacheNexusPixels
> nonspec time: 46.60
> time :     36.18
> size:        87
> 
> 
> Since the insns number 87 of callee function is bigger than inline_insns_auto
> (30) and there is no hint, so inline depends on "big_speedup_p (e)". 484.08
> (caller_time) * 0.15 (param_inline_min_speedup == 15)   = 72.61,  which
> means callee's time should be at least 72.61, but callee's time is 46.60, so we
> need to lower param_inline_min_speedup to 3 or 4. I checked the
> history(https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=8366
> 5), that you tried changing it to 8,  but that increases the gzip code size by
> 2.5KB. so I want to add a heuristic hit for it.
> 
> Thanks,
> Lili.
> >
> > Honza