https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #7 from Pat Haugen ---
Created attachment 43901
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43901=edit
inline dump
Prior attachment was r257581 dump. This is r257582 dump.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #6 from Pat Haugen ---
Created attachment 43900
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43900=edit
inline dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #5 from Pat Haugen ---
A little more detail. 48t.fnsplit splits mainGtU() into 2 functions:
mainGtU(): which contains a few early exit tests and then a call to
mainGtU.part.0()
mainGtU.part.0(): contains the remainder of mainGtU(),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #4 from Richard Biener ---
Honza?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #3 from Pat Haugen ---
(In reply to Jan Hubicka from comment #1)
> Pat, can you try to figure out what value of min-speedup is neeed to recover
> from this regression?
Using r257582, either of the following options restores the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #2 from Pat Haugen ---
(In reply to Pat Haugen from comment #0)
>
> Very initial look at profile of bzip2 shows degradation is contained to
> mainSort(), which showed a 54% increase in run cycles. Appears one of the
> calls to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #1 from Jan Hubicka ---
Pat, can you try to figure out what value of min-speedup is neeed to recover
from this regression?
It woul be nice to know what is the particular inline decision causing trouble
and what are the esitmated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target
