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.


  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: link
Be 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).