This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/40106] [4.4/4.5 Regression] Weird interaction between optimize_insn_for_speed_p and -funsafe-math-optimizations



------- Comment #52 from rguenther at suse dot de  2010-03-20 14:19 -------
Subject: Re:  [4.4/4.5 Regression] Weird interaction
 between optimize_insn_for_speed_p and -funsafe-math-optimizations

On Sat, 20 Mar 2010, dominiq at lps dot ens dot fr wrote:

> ------- Comment #51 from dominiq at lps dot ens dot fr  2010-03-20 13:21 -------
> The following patch fixes this pr:
> 
> --- ../_clean/gcc/predict.c     2009-11-25 18:20:33.000000000 +0100
> +++ gcc/predict.c       2010-03-20 14:03:33.000000000 +0100
> @@ -251,7 +251,7 @@ optimize_edge_for_speed_p (edge e)
>  bool
>  optimize_insn_for_size_p (void)
>  {
> -  return optimize_function_for_size_p (cfun) || !crtl->maybe_hot_insn_p;
> +  return optimize_function_for_size_p (cfun) && !crtl->maybe_hot_insn_p;
>  }
> 
>  /* Return TRUE when BB should be optimized for speed.  */
> 
> If the optimize_*_p procs are intended to allow optimization for speed with -Os
> and "hot" part of codes, it seems that the logic of the implementation should
> be checked carefully.

optimize_function_for_size_p (cfun) is true if attribute(cold) is set
on it or we are optimizing for size.

The only issue that exists with the predicates is that they are
implemented symmetrically (optimize_*_for_speed_p is 
!optimize_*_for_size_p) but the low-level implementations check
for extremes like FUNCTION_FREQUENCY_UNLIKELY_EXECUTED where
negation would be FUNCTION_FREQUENCY_HOT, not
FUNCTION_FREQUENCY_HOT || FUNCTION_FREQUENCY_NORMAL.

Thus, for example optimize_function_for_size_p would better read

  if (fun && fun->function_frequency == 
FUNCTION_FREQUENCY_UNLIKELY_EXECUTED)
   return true;
 else if (fun && fun->function_frequency == FUNCTION_FREQUENCY_HOT)
   return false
 return optimize_size;

thus optimize_size should be the default that applies when the
(guessed) profile doesn't give a strong hint.

Likewise optimize_bb_for_size_p needs to disregard the case where
optimize_function_for_size_p returns optimize_size and only then
ask maybe_hot_bb_p.  Thus there should be low-level fns that
return a tri-state, true, false and "default".

But that's all too much change for 4.5.  Eventually you can
play with adjusting just optimize_function_for_size_p as indicated
above.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]