public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mtewoodbury at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59193] Unused postfix operator temporaries
Date: Thu, 20 Feb 2014 02:48:00 -0000	[thread overview]
Message-ID: <bug-59193-4-W3goZPY7uQ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-59193-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Max TenEyck Woodbury <mtewoodbury at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---
           Severity|minor                       |trivial

--- Comment #8 from Max TenEyck Woodbury <mtewoodbury at gmail dot com> ---
Re: Manuel López-Ibáñez

Yes, as soon as I feel that my efforts will not be ignored, as they have been
so far...

Re:  Jakub Jelinek

You admit that different 'tree codes' are generated, so there is a difference
between the two sequences.  You further admit that -O0 does do some
optimization, otherwise the machine code emitted would store and discard
the temporary value because that is what the language standard says should
happen.  While this is quite trivial in practice, it shows that you place
your opinion over the exact semantics called for by the standard and lack
the ability to see that.  That is distinctly disturbing.
>From gcc-bugs-return-444286-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 20 02:52:34 2014
Return-Path: <gcc-bugs-return-444286-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3612 invoked by alias); 20 Feb 2014 02:52:34 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3580 invoked by uid 55); 20 Feb 2014 02:52:31 -0000
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
Date: Thu, 20 Feb 2014 02:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-58555-4-D29bZxCpnv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58555-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58555-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg02043.txt.bz2
Content-length: 4421

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX555

--- Comment #25 from Jan Hubicka <hubicka at ucw dot cz> ---
> It is easier to just return at beggining instead of duplicating the check.
> Have patch for it, just for some reason
> I wanted to look deper into why we inline here.  I forgot the reason, but will
> work it out again today.
OK, remember the reason, the inlining decisions did not make sense :)

It turned out to be very basic and apparently ages old profile updating but in
clone_inlined_nodes. This function is used when one inlines call a->b
and it produces clone of b to be inlined into a.  It updates frequencies in
the clone, so if the edge is, say, executing twice per invocation of a,
the frequencies in b are doubled.

Now it may happen that b has inlined functions to it. In that case the function
recurses and inlines further. It stil updates frequencies on the same basis:
i.e. it takes average number of executions of edge per invocation and multiply.
This is completely wrong.  If there is chain b->c->d->e all inlined and c is
executed at average 10 times per execution of b and c->d, the the frequenceis
of edge c->d->e are already scaled up 10fold.
The current logic sees edge c->d already multiplied and scale again causing
quite an explosion in frequencies.

Bootstrapping/regtesting x86_64-linux.

Index: ipa-inline.c
==================================================================--- ipa-inline.c    (revision 207870)
+++ ipa-inline.c    (working copy)
@@ -708,6 +684,12 @@
   if (outer_node->global.inlined_to)
     caller_freq = outer_node->callers->frequency;

+  if (!caller_freq)
+    {
+      reason = "function is inlined and ulikely";
+      want_inline = false;
+    }
+
   if (!want_inline)
     ;
   /* Inlining of self recursive function into copy of itself within other
function
Index: ipa-inline.h
==================================================================--- ipa-inline.h    (revision 207870)
+++ ipa-inline.h    (working copy)
@@ -233,7 +234,8 @@
 /* In ipa-inline-transform.c  */
 bool inline_call (struct cgraph_edge *, bool, vec<cgraph_edge_p> *, int *,
bool);
 unsigned int inline_transform (struct cgraph_node *);
-void clone_inlined_nodes (struct cgraph_edge *e, bool, bool, int *);
+void clone_inlined_nodes (struct cgraph_edge *e, bool, bool, int *,
+              int freq_scale = -1);

 extern int ncalls_inlined;
 extern int nfunctions_inlined;
Index: ipa-inline-transform.c
==================================================================--- ipa-inline-transform.c    (revision 207870)
+++ ipa-inline-transform.c    (working copy)
@@ -127,11 +127,16 @@
    the edge and redirect it to the new clone.
    DUPLICATE is used for bookkeeping on whether we are actually creating new
    clones or re-using node originally representing out-of-line function call.
-   */
+   By default the offline copy is removed, when it appers dead after inlining.
+   UPDATE_ORIGINAL prevents this transformation.
+   If OVERALL_SIZE is non-NULL, the size is updated to reflect the
+   transformation.
+   FREQ_SCALE is implicit parameter used for internal bookeeping when
+   recursively copying functions inlined into the clone.  */

 void
 clone_inlined_nodes (struct cgraph_edge *e, bool duplicate,
-             bool update_original, int *overall_size)
+             bool update_original, int *overall_size, int freq_scale)
 {
   struct cgraph_node *inlining_into;
   struct cgraph_edge *next;
@@ -171,12 +176,16 @@
       duplicate = false;
       e->callee->externally_visible = false;
           update_noncloned_frequencies (e->callee, e->frequency);
+      gcc_assert (freq_scale == -1);
     }
       else
     {
       struct cgraph_node *n;
+
+      if (freq_scale == -1)
+        freq_scale = e->frequency;
       n = cgraph_clone_node (e->callee, e->callee->decl,
-                 e->count, e->frequency, update_original,
+                 e->count, freq_scale, update_original,
                  vNULL, true, inlining_into);
       cgraph_redirect_edge_callee (e, n);
     }
@@ -191,7 +200,7 @@
     {
       next = e->next_callee;
       if (!e->inline_failed)
-        clone_inlined_nodes (e, duplicate, update_original, overall_size);
+        clone_inlined_nodes (e, duplicate, update_original, overall_size,
freq_scale);
       if (e->speculative && !speculation_useful_p (e, true))
     {
       cgraph_resolve_speculation (e, NULL);


  parent reply	other threads:[~2014-02-20  2:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-59193-4@http.gcc.gnu.org/bugzilla/>
2013-11-19 16:41 ` joseph at codesourcery dot com
2013-11-20  0:59 ` pinskia at gcc dot gnu.org
2014-02-05  9:07 ` mpolacek at gcc dot gnu.org
2014-02-12 19:22 ` mtewoodbury at gmail dot com
2014-02-12 19:30 ` pinskia at gcc dot gnu.org
2014-02-19  6:15 ` mtewoodbury at gmail dot com
2014-02-19  9:58 ` pinskia at gcc dot gnu.org
2014-02-19 10:18 ` jakub at gcc dot gnu.org
2014-02-20  2:48 ` mtewoodbury at gmail dot com [this message]
2014-02-20  6:15 ` pinskia at gcc dot gnu.org
2014-02-22  2:03 ` mtewoodbury at gmail dot com
2014-02-22  4:19 ` pinskia at gcc dot gnu.org
2014-02-22 11:10 ` mtewoodbury at gmail dot com
2014-06-25 11:27 ` mpolacek 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-59193-4-W3goZPY7uQ@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).