public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level Date: Wed, 18 Mar 2015 09:02:00 -0000 [thread overview] Message-ID: <bug-64164-4-6xp7PLbv2t@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-64164-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Alexandre Oliva from comment #9) > (In reply to Jeffrey A. Law from comment #7) > > OK, but why does this make such a difference in the final result. Ie, what happens as we get into RTL. > > Err, I covered that bit in my description: we emit a number of copies, each > with a new BB of its own. The additional pseudo survives all the way to the > end, and so do the copies, which is enough to explain the additional stack > slot. Further rearrangement of code also follows from the additional blocks. > > (In reply to Andrew Macleod from comment #8) > > most of these kinds of restrictions were rooted in some kind of rationale... usually from examining an issue of some sort and introducing the restriction to avoid it. > > This one was added by > https://gcc.gnu.org/ml/gcc-patches/2012-08/msg00517.html > The description mentions out-of-SSA coalescing, but not copyrename > coalescing, which is what this is about. Since there were not anonymous SSA > names before, the introduced condition would necessarily not be met, so it > effectively reduced the amount of copyrename coalescing without any > rationale AFAICT. > > Richi, do you happen to have any insight as to why you changed copyrename to > avoid coalescing rootless ssa names? Because "coalescing" them doesn't do anything. copyrename coalescing assigns the same underlying DECL to SSA names, thus makes SSA_NAME_VAR the same. But when both SSA_NAME_VARs are NULL this won't do anything. So the effect of the patch was rather that there are now way less SSA names with SSA_NAME_VAR != NULL. In particular all the pass created ones (with no relation to user declared variables). It didn't make sense to apply copyrename to those (copyrename is to have better debug info in the end, sth which should be provided by debug stmts today). > Reverting it doesn't seem to have any > ill effects on code correctness (unlike allowing coalescing between rooted > and rootless vars during out-of-ssa, in gimple_can_coalesce_p, which breaks > codegen badly, though I haven't dug into why). I'll attach a patch I'm > testing to that effect momentarily. So I'd say the patch can't make a difference - it at most can end up re-writing the type of an SSA name and then having followup effects in out-of-SSA coalescing? For some odd reason we are ignoring some type differences in copyrename coalescing. But - how does either root1 or root2 end up non-zero at /* Set the root variable of the partition to the better choice, if there is one. */ if (!ign2 && root2) replace_ssa_name_symbol (partition_to_var (map, p3), root2); else if (!ign1 && root1) replace_ssa_name_symbol (partition_to_var (map, p3), root1); else gcc_unreachable (); ? That is, the only effect of your patch is to do partiton_union? Ah, and then go to: /* Now one more pass to make all elements of a partition share the same root variable. */ for (x = 1; x < num_ssa_names; x++) { part_var = partition_to_var (map, x); if (!part_var) continue; var = ssa_name (x); if (SSA_NAME_VAR (var) == SSA_NAME_VAR (part_var)) continue; if (debug) { fprintf (debug, "Coalesced "); print_generic_expr (debug, var, TDF_SLIM); fprintf (debug, " to "); print_generic_expr (debug, part_var, TDF_SLIM); fprintf (debug, "\n"); } stats.coalesced++; replace_ssa_name_symbol (var, SSA_NAME_VAR (part_var)); } and wreck SSA names type (and "debug" identifier) only? That really sounds bogus. The correct fix would be to allow the kind of type differences copyrename coalescing allows also in out-of-SSA coalescing. That is, I don't see how the patch makes sense.
next prev parent reply other threads:[~2015-03-18 9:02 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-12-03 9:33 [Bug ipa/64164] New: " patrick.marlier at gmail dot com 2014-12-03 9:44 ` [Bug middle-end/64164] " pinskia at gcc dot gnu.org 2014-12-03 9:45 ` pinskia at gcc dot gnu.org 2014-12-03 10:03 ` [Bug rtl-optimization/64164] " rguenth at gcc dot gnu.org 2014-12-03 10:06 ` rguenth at gcc dot gnu.org 2014-12-11 11:46 ` rguenth at gcc dot gnu.org 2014-12-17 11:38 ` patrick.marlier at gmail dot com 2015-03-17 18:19 ` law at redhat dot com 2015-03-17 19:55 ` amacleod at redhat dot com 2015-03-17 22:15 ` aoliva at gcc dot gnu.org 2015-03-17 22:18 ` aoliva at gcc dot gnu.org 2015-03-17 22:19 ` aoliva at gcc dot gnu.org 2015-03-17 23:01 ` aoliva at gcc dot gnu.org 2015-03-18 0:20 ` aoliva at gcc dot gnu.org 2015-03-18 5:48 ` law at redhat dot com 2015-03-18 9:02 ` rguenth at gcc dot gnu.org [this message] 2015-03-18 9:03 ` rguenth at gcc dot gnu.org 2015-03-18 9:19 ` rguenth at gcc dot gnu.org 2015-03-18 10:05 ` aoliva at gcc dot gnu.org 2015-03-18 10:16 ` rguenther at suse dot de 2015-03-18 10:18 ` aoliva at gcc dot gnu.org 2015-03-19 5:17 ` aoliva at gcc dot gnu.org 2015-03-20 8:07 ` law at redhat dot com 2015-03-20 10:03 ` rguenther at suse dot de 2015-03-20 20:44 ` law at redhat dot com 2015-03-27 18:26 ` aoliva at gcc dot gnu.org 2015-03-29 20:58 ` aoliva at gcc dot gnu.org 2015-03-30 23:06 ` patrick.marlier at gmail dot com 2015-03-30 23:09 ` law at redhat dot com 2015-03-30 23:34 ` law at redhat dot com 2015-03-31 12:21 ` [Bug rtl-optimization/64164] [4.9/5/6 " rguenth at gcc dot gnu.org 2015-03-31 12:21 ` [Bug rtl-optimization/64164] [4.9/5 " rguenth at gcc dot gnu.org 2015-03-31 12:56 ` [Bug rtl-optimization/64164] [4.9/5/6 " jakub at gcc dot gnu.org 2015-04-01 7:51 ` rguenth at gcc dot gnu.org 2015-06-09 5:06 ` aoliva at gcc dot gnu.org 2015-06-09 5:34 ` [Bug rtl-optimization/64164] [4.9/5 " aoliva at gcc dot gnu.org 2015-06-09 9:10 ` ebotcazou at gcc dot gnu.org 2015-06-09 16:35 ` dje at gcc dot gnu.org 2015-06-10 0:15 ` [Bug rtl-optimization/64164] [4.9/5/6 " aoliva at gcc dot gnu.org 2015-06-10 13:16 ` clyon at gcc dot gnu.org 2015-06-10 14:43 ` dje at gcc dot gnu.org 2015-06-10 14:45 ` dje at gcc dot gnu.org 2015-07-23 15:35 ` aoliva at gcc dot gnu.org 2015-07-24 10:37 ` schwab@linux-m68k.org 2015-07-24 10:51 ` schwab@linux-m68k.org 2015-07-24 16:57 ` sje at gcc dot gnu.org 2015-07-27 9:07 ` ro at gcc dot gnu.org 2015-07-30 18:20 ` aoliva at gcc dot gnu.org 2015-08-02 21:11 ` gary at intrepid dot com 2015-08-14 18:52 ` aoliva at gcc dot gnu.org 2015-08-15 2:24 ` aoliva at gcc dot gnu.org 2015-08-15 2:25 ` aoliva at gcc dot gnu.org 2015-08-15 2:25 ` aoliva at gcc dot gnu.org 2015-08-15 2:26 ` aoliva at gcc dot gnu.org 2015-08-15 2:26 ` aoliva at gcc dot gnu.org 2015-08-15 2:27 ` aoliva at gcc dot gnu.org 2015-08-19 17:01 ` aoliva at gcc dot gnu.org 2015-08-21 20:04 ` aoliva at gcc dot gnu.org 2015-08-21 20:05 ` aoliva at gcc dot gnu.org 2015-09-23 21:13 ` aoliva at gcc dot gnu.org 2015-09-27 9:03 ` aoliva at gcc dot gnu.org 2015-09-27 12:13 ` trippels at gcc dot gnu.org 2015-09-28 1:15 ` aoliva at gcc dot gnu.org 2015-09-28 1:16 ` aoliva at gcc dot gnu.org 2015-09-28 1:16 ` aoliva at gcc dot gnu.org 2015-10-09 12:21 ` aoliva at gcc dot gnu.org 2015-10-09 12:22 ` aoliva 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-64164-4-6xp7PLbv2t@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).