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 tree-optimization/59967] [4.8/4.9 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)


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

--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> ---
> 193246    hubicka       /* If there is call on a hot path through the loop,
> then
> 193246    hubicka        there is most probably not much to optimize.  */
> 193246    hubicka       else if (size.num_non_pure_calls_on_hot_path)
> 138522    rguenth       {
> 138522    rguenth         if (dump_file && (dump_flags & TDF_DETAILS))
> 193246    hubicka           fprintf (dump_file, "Not unrolling loop %d: "
> 193246    hubicka                    "contains call and code would grow.\n",
> 138522    rguenth                    loop->num);
> 138522    rguenth         return false;
> 138522    rguenth       }
> 
> so we conclude
> 
> size: 59-8, last_iteration: 52-5
>   Loop size: 59
>   Estimated size after unrolling: 269
> Not unrolling loop 2: contains call and code would grow.
> 
> so it was disabled on purpose.  Not sure if it's worth special-casing
> self-recursive calls the same as pure/const ones.

Not by the logic above, because self recursion is not really better understood
by optimizers than normal function calls.  I am surprised the unroling makes
10-15% difference in this case then. Is there something that makes the unrolled
loop to optimize better?

Honza


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