This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/59967] [4.8/4.9 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)
- From: "hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 02 Apr 2014 23:17:11 +0000
- Subject: [Bug tree-optimization/59967] [4.8/4.9 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)
- Auto-submitted: auto-generated
- References: <bug-59967-4 at http dot gcc dot gnu dot org/bugzilla/>
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