public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jamborm at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a
Date: Thu, 17 Feb 2022 22:33:31 +0000	[thread overview]
Message-ID: <bug-103195-4-Ia4Fe6nx02@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103195-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103195

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #7 from Martin Jambor <jamborm at gcc dot gnu.org> ---
(In reply to hubicka from comment #6)
> Yep, unit growths do not apply for very small units.  ipa-cp heuristics
> still IMO needs work and be based on relative speedups rather then
> absolute for the cutoffs.

I'll be happy to discuss how to change IPA-CP cost/benefit
estimations (ideally in person next to a whiteboard) but I am somewhat
wary of making the heuristics even more similar to the inliner as then
all clones will be inlined.

Moreover, the problem here is that the constant leads to a loop with
known number of iterations, even if it is executed with expected
relative frequency of just 0.47, and the extra points it gets for this
help it get over the limit.  (Would you suggest to scale the bonus by
the nonspec time somehow?)

The bonus for known loop iteration count is arguably too large.  In
current master, exchange2_r would be fine with less than half, even in
the PGO case.  We could also scale the bonus not linearly by estimated
frequency of the loop but by... I don't know... its square :-)

Looking at the code I also discovered that I (probably) forgot to
delete the old addition of a constant bonus and so we scale by
1+frequency rather than the frequency.

The simplest way of dealing with this issue would be to have a cut-off
frequency for the bonus, like the following which declares all loops
that are executed with estimated frequency less than 1/2 as
uninteresting:

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 453e9c93cc3..c9f419c5b34 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -3257,15 +3257,14 @@ hint_time_bonus (cgraph_node *node, const
ipa_call_estimates &estimates)
 { 
   int result = 0;
   ipa_hints hints = estimates.hints;
-  if (hints & (INLINE_HINT_loop_iterations | INLINE_HINT_loop_stride))
-    result += opt_for_fn (node->decl, param_ipa_cp_loop_hint_bonus);
-  
   sreal bonus_for_one = opt_for_fn (node->decl, param_ipa_cp_loop_hint_bonus);

-  if (hints & INLINE_HINT_loop_iterations)
+  if (hints & INLINE_HINT_loop_iterations
+      && estimates.loops_with_known_iterations >= sreal (1, -1))
     result += (estimates.loops_with_known_iterations * bonus_for_one).to_int
();

-  if (hints & INLINE_HINT_loop_stride)
+  if (hints & INLINE_HINT_loop_stride
+      && estimates.loops_with_known_strides >= sreal (1, -1))
     result += (estimates.loops_with_known_strides * bonus_for_one).to_int ();

   return result;

  parent reply	other threads:[~2022-02-17 22:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 17:44 [Bug tree-optimization/103195] New: tfft2 text grows by 70% with -Ofast between g:52fa771758635d9c53cddb9116e5a66fae592230...a97fdde627e64202940112009d45d17f85e4cc61 hubicka at gcc dot gnu.org
2021-11-12  7:39 ` [Bug tree-optimization/103195] " rguenth at gcc dot gnu.org
2021-11-12 10:12 ` [Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a marxin at gcc dot gnu.org
2021-11-12 10:27 ` hubicka at kam dot mff.cuni.cz
2021-11-12 21:25 ` hubicka at gcc dot gnu.org
2021-11-16 13:10 ` rguenth at gcc dot gnu.org
2022-01-18 14:29 ` rguenth at gcc dot gnu.org
2022-01-18 14:31   ` Jan Hubicka
2022-01-18 14:31 ` hubicka at kam dot mff.cuni.cz
2022-02-17 22:33 ` jamborm at gcc dot gnu.org [this message]
2022-05-06  8:31 ` [Bug tree-optimization/103195] [12/13 " jakub at gcc dot gnu.org
2022-07-26 13:10 ` rguenth 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-103195-4-Ia4Fe6nx02@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).