public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/48636] Enable more inlining with -O2 and higher Date: Sun, 17 Apr 2011 10:44:00 -0000 [thread overview] Message-ID: <bug-48636-4-4FC0bSEIFq@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-48636-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-04-17 10:44:23 UTC --- I am slowly starting to look into fortran issues now. For years it was non-issue since we had the non-one-decl-per-function problem. This is finally solved One additional problem is that we often hit large-stack frame limits because the fortran i/o drops large datastructure on stack. Consequently any functions that do i/o (for debug purposes, for example) are not inlined into functions that doesn't. We will need to relax this. - Consider heuristics to mark functions as inline in the front end: - If it has many arguments (argument processing has a lot of effect) - If it uses assumed-shape arrays (setting up that array descriptor may take a lot of time - Mark everything as inline I briefly discussed option of marking everything as inline on IRC for 4.6.x series but it did not go well with Richard. Observation is that dominating coding style in fortran is to not care that much about code size if perfomrance improve and inlining do help here. In longer term it would be cool if inliner was able to work out as much as possible himself w/o frontend help. The first item you mention is something backend can do at its own (and it already knows how to benefit many arguments, but it proably does not do it enough to make difference for fortran). I am just about commit patch that makes backend by hair more sensitive on this. The second item is interesting - it would be cool if backend was able to work out that the code is supposed to simplify after inlining. Either by itself or by frontend hint. Can you provide me very simple testcase for that I can look into how it looks like in backend? Perhaps some kind of frontend hinting would work well here. Honza
next prev parent reply other threads:[~2011-04-17 10:44 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-15 21:05 [Bug fortran/48636] New: " tkoenig at gcc dot gnu.org 2011-04-16 11:22 ` [Bug fortran/48636] " rguenth at gcc dot gnu.org 2011-04-17 10:23 ` dominiq at lps dot ens.fr 2011-04-17 10:44 ` hubicka at gcc dot gnu.org [this message] 2011-04-17 13:32 ` tkoenig at gcc dot gnu.org 2011-04-17 14:12 ` dominiq at lps dot ens.fr 2011-04-20 11:22 ` jb at gcc dot gnu.org 2011-04-20 12:29 ` burnus at gcc dot gnu.org 2011-04-20 13:10 ` jb at gcc dot gnu.org 2011-04-20 15:42 ` burnus at gcc dot gnu.org 2011-04-20 16:41 ` tkoenig at gcc dot gnu.org 2011-04-20 18:15 ` jb at gcc dot gnu.org 2011-05-04 16:23 ` hubicka at gcc dot gnu.org 2011-05-04 17:31 ` burnus at gcc dot gnu.org 2011-06-04 18:08 ` hubicka at gcc dot gnu.org 2012-07-03 17:44 ` jamborm at gcc dot gnu.org 2012-08-11 10:50 ` jamborm at gcc dot gnu.org 2012-08-21 6:54 ` hubicka at gcc dot gnu.org 2012-08-21 8:15 ` hubicka at gcc dot gnu.org 2012-09-12 21:52 ` hubicka at gcc dot gnu.org 2012-10-16 16:39 ` hubicka at gcc dot gnu.org 2012-10-16 17:58 ` dominiq at lps dot ens.fr 2012-10-16 20:59 ` dominiq at lps dot ens.fr 2012-10-17 12:20 ` jakub at gcc dot gnu.org 2012-10-17 13:13 ` dominiq at lps dot ens.fr 2012-10-17 14:06 ` dominiq at lps dot ens.fr 2012-10-19 8:45 ` vincenzo.innocente at cern dot ch 2012-10-20 10:35 ` hubicka at gcc dot gnu.org 2012-10-20 11:22 ` dominiq at lps dot ens.fr 2012-10-20 12:11 ` tkoenig at gcc dot gnu.org 2012-10-28 10:08 ` hubicka at gcc dot gnu.org 2012-10-28 10:11 ` hubicka at gcc dot gnu.org 2012-10-28 11:27 ` vincenzo.innocente at cern dot ch 2012-11-07 9:34 ` hubicka at gcc dot gnu.org 2012-11-07 11:18 ` hubicka at gcc dot gnu.org 2012-11-08 16:46 ` hubicka at gcc dot gnu.org 2012-11-11 18:15 ` hubicka at gcc dot gnu.org 2012-11-12 12:16 ` hubicka at gcc dot gnu.org 2012-11-12 12:45 ` izamyatin at gmail dot com 2012-11-14 23:22 ` hubicka at gcc dot gnu.org 2012-11-14 23:54 ` Jan Hubicka 2012-11-14 23:55 ` hubicka at ucw dot cz 2012-11-15 2:29 ` hubicka at gcc dot gnu.org 2012-11-16 14:43 ` dominiq at lps dot ens.fr 2013-03-01 17:49 ` wschmidt at gcc dot gnu.org 2013-03-04 17:54 ` wschmidt at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-48636-4-4FC0bSEIFq@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).