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

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

> -----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=83665), 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