https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #25 from Jan Hubicka hubicka at gcc dot gnu.org ---
Crafty perfomrance is back (with a combination of better heuristics and
increase of inlining limits), eon is not, at least not in all configurations.
We have separate eon PR, so I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #24 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 1 Apr 2015, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #23 from Jan Hubicka hubicka at ucw dot cz ---
Seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #23 from Jan Hubicka hubicka at ucw dot cz ---
Seems to be a regression with -flto only? I also see EON regressing without
-flto.
Yes, the inlining is cross file.
http://gcc.opensuse.org/SPEC/CINT/sb-megrez-head-64/index.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #20 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 30 Mar 2015, hubicka at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #16 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #15)
The inline bump needed is about 23. Richard, i guess convincing early
optimizers to turn that hack into shifts (that is done by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #17 from Jan Hubicka hubicka at ucw dot cz ---
bb 2:
x.d = arg1_3(D);
_5 = x.i[3];
if (_5 != 0)
goto bb 3;
else
goto bb 4;
...
bb 4:
_12 = x.i[2];
if (_12 != 0)
goto bb 5;
else
goto bb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org ---
Actually at second thought, would BIT_FIELD_REF arg1_3(D), ... allow us to
avoid the actual memory store? I tought like COMPONENT_REF it takes address as
parameter. What I am hoping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #18 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Richard Biener from comment #16)
But yes, in principle we can do sth fancy for union loads, though I'd
use BIT_FIELD_REFs (hoping no issues wrt endian...) as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenther at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org ---
Author: hubicka
Date: Sun Mar 29 15:38:52 2015
New Revision: 221763
URL: https://gcc.gnu.org/viewcvs?rev=221763root=gccview=rev
Log:
PR ipa/65478
* params.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org ---
The inline bump needed is about 23. Richard, i guess convincing early
optimizers to turn that hack into shifts (that is done by GCC but only at RTL
time), is out of reach for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #12 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #9)
Actually, there is one detail. Cloning SCC and keeping it a SCC is cool
thing (as one avoid passing constant parameter across the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 35159
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35159action=edit
Patch implementing cloning penalties
(In reply to Martin Jambor from comment #8)
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
This suggests that cloning of function Search and not inlining
NextMove is only part of the story.
I'm attaching output of my script that compares inlining decisions.
File 1 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
CC||jamborm at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 35127
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35127action=edit
Inlining decisions difference
(In reply to Martin Jambor from comment #6)
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz ---
We also may consider adding bit of negative hints for cases where
cloning would turn function called once (by noncold edge) to a
function called twice.
This would be much easier,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
Thre regression seems to be visible at
http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-ai-64/186_crafty_big.png
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz ---
Which options (LTO?)? I can't see the regression on our testers.
-Ofast -flto -funroll-loops
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Component|tree-optimization |ipa
25 matches
Mail list logo
