https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Eric Gallager changed:
What|Removed |Added
Assignee|hubicka at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2012-06-29 11:27:01 |2013-03-29
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2008-01-23 11:27:01 |2012-06-29 11:27:01
--- Comment #15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #14 from Jan Hubicka 2010-11-10 23:05:25
UTC ---
> Note that the IO block escapes and thus cannot be coalesced with others in
> the same function. I had a frontend patch to re-use the same IO struct
> across multiple calls but that w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #13 from Richard Guenther 2010-11-10
22:54:51 UTC ---
Btw, the old "kill stmt" idea would be a useful thing to insert for the
frontend
to mark the end of life of IO struct contents.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #12 from Richard Guenther 2010-11-10
22:53:46 UTC ---
Note that the IO block escapes and thus cannot be coalesced with others in
the same function. I had a frontend patch to re-use the same IO struct
across multiple calls but that wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #11 from Jan Hubicka 2010-11-10 22:50:08
UTC ---
Ok, it might be interesting to run some fortran benchmarks with the
large-stack-frame parameter
bumped up. If it helps, I think we can just do so for 4.6.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #10 from Jakub Jelinek 2010-11-10
22:43:31 UTC ---
Because one IO command is split into several function calls and a state has to
be preserved in between those.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #9 from Jan Hubicka 2010-11-10 22:35:46 UTC
---
The inline heuristics should take that into account. But at the moment
io block simply always prevent inlining function with IO into function without
IO.
We consider function with more t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Jan Hubicka changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Jan Hubicka changed:
What|Removed |Added
CC||bur...@net-b.de, hubicka at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-23 17:22 ---
just a note, ifort does inline the function cs1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-23 15:45 ---
(In reply to comment #2)
> It's considered too big and it's not static.
>
not sure if my C is good enough to reply, but CS1 is visible only from within
the subroutine S1. That's somewhat similar to (or stricter than) '
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-23 13:55 ---
Considering cs1 with 52 insns
to be inlined into s1
Estimated growth after inlined into all callees is -13 insns.
Estimated badness is 86, frequency 1.00.
Not inlining into s1:--param large-stack-frame-growth lim
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-23 13:54 ---
It's considered too big and it's not static.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-23 11:27 ---
It is not always a win. A function called once on a cold path should not be
inlined for e.g. icache reasons.
For your test case however, CS1 should have been inlined.
--
steven at gcc dot gnu dot org changed:
19 matches
Mail list logo
