[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Most of the regression caused by the inlining difference is fixed now, but the
solution is not ideal.
According to Czerny we still have quite noticeable regression
https://gcc.opensuse.org/c++bench-czerny/c-ray/ and code size is bigger.

Morever we get noticeable code size growth in wave (808569->814865, 0.8%) and
Botan (1780199->1789329)

The other change is
160810 0.33 30089 13360 2281 
160811 0.27 30089 12656 2560 
Perhaps this patch might be a suspect, but I have no idea
2016-08-10  Yuri Rumyantsev  <ysrumyan@gmail.com>                               

        PR tree-optimization/71734                                              
        * tree-ssa-loop-im.c (ref_indep_loop_p): Add new argument               
        REF_LOOP, invoke ref_indep_loop_p_1.                                    
        (outermost_indep_loop): Pass LOOP argumnet where REF was defined        
        to ref_indep_loop_p.                                                    
        (ref_indep_loop_p_1): Fix commentary, add argument REF_LOOP,            
        combine it with ref_indep_lopp_p_2, update SAFELEN if only REF          
        is inside LOOP, do not cache dpendence value for loops with             
        non-zero SAFELEN.                                                       
        (ref_indep_loop_p_2): Delete function.                                  
        (can_sm_ref_p): Pass LOOP as additional argument to                     
        ref_indep_loop_p.                                                       


One more important issue I noticed is that inline metric always compare the
estimated runtime of offline copy with the runtime of specialized copy after
inlining (with known constants and other context). 

This is OK for size metrics, but not OK for speed.  The offline copy is run in
the same context, in particular if some code is guarded by a conditional that
is false, it is not executed and should not be acocunted to offline path.  This
makes the inline metric to be skewed toward inlining which eliminates large
conditionals.  I will fix that in next stage1, but I am not sure how much we
can still do in current stage4.

One observation is that overall runtime/size estimates after early opt has
quite improved in last two releases where I did not do re-tunning of
parameters. Perhaps it is time to tune down a bit early inlining and
inline-insns-auto again...