[Bug tree-optimization/103195] New: tfft2 text grows by 70% with -Ofast between g:52fa771758635d9c53cddb9116e5a66fae592230...a97fdde627e64202940112009d45d17f85e4cc61

[Bug tree-optimization/103195] New: tfft2 text grows by 70% with -Ofast between g:52fa771758635d9c53cddb9116e5a66fae592230...a97fdde627e64202940112009d45d17f85e4cc61

[hubicka at gcc dot gnu.org]

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

            Bug ID: 103195
           Summary: tfft2 text grows by 70% with -Ofast between
                    g:52fa771758635d9c53cddb9116e5a66fae592230...a97fdde62
                    7e64202940112009d45d17f85e4cc61
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is seen at LTN here

https://lnt.opensuse.org/db_default/v4/CPP/24179
https://lnt.opensuse.org/db_default/v4/CPP/graph?highlight_run=24179&plot.0=14.799.4

and similarly on other testers.  Performance is not improved so it looks like
bit extreme even for -Ofast. It would be nice to know why such growth happens.

[Bug tree-optimization/103195] tfft2 text grows by 70% with -Ofast between g:52fa771758635d9c53cddb9116e5a66fae592230...a97fdde627e64202940112009d45d17f85e4cc61

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
threader stuff would be my bet, but we need to bisect this (tfft2 is also quite
small)

[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
             Status|UNCONFIRMED                 |NEW
                 CC|                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
            Summary|tfft2 text grows by 70%     |[12 Regression] tfft2 text
                   |with -Ofast between         |grows by 70% with -Ofast
                   |g:52fa771758635d9c53cddb911 |since
                   |6e5a66fae592230...a97fdde62 |r12-5113-gd70ef65692fced7a
                   |7e64202940112009d45d17f85e4 |
                   |cc61                        |
   Last reconfirmed|                            |2021-11-12

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> threader stuff would be my bet, but we need to bisect this (tfft2 is also
> quite small)

Bad bet ;) It's caused by r12-5113-gd70ef65692fced7a.

[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[hubicka at kam dot mff.cuni.cz]

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

--- Comment #3 from hubicka at kam dot mff.cuni.cz ---
> > threader stuff would be my bet, but we need to bisect this (tfft2 is also
> > quite small)
> 
> Bad bet ;) It's caused by r12-5113-gd70ef65692fced7a.

Hehe, that was my guess yeterday.  Thanks for confirming.  So now to
figure out why better alias info makes tfft2 grow.  I guess more
vectorization?

Thanks for bisecting this

[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjambor at suse dot cz

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, quite surprisingly the code size growth is due to ipa-cp.
Due to early modref, we get two aggregate jump functions:

          value: 0x0, mask: 0xffffffffffffffe0
          VR  [1, -1]
        param 3: UNKNOWN
+         Aggregate passed by reference:
+           offset: 0, type: integer(kind=4), CONST: 33554432
          value: 0x0, mask: 0xfffffffffffffffc
          VR  [1, -1]
        param 4: CONST: &C.4517 -> -1
@@ -747,6 +744,8 @@
          value: 0x0, mask: 0xffffffffffffffe0
          VR  [1, -1]
        param 3: UNKNOWN
+         Aggregate passed by reference:
+           offset: 0, type: integer(kind=4), CONST: 33554432
          value: 0x0, mask: 0xfffffffffffffffc
          VR  [1, -1]
        param 4: CONST: &C.4512 -> 1

and later we decide to clone:

+   Estimating body: rfft/1
+   Known to be false: op3[ref offset: 0] <= 0, op3[ref offset: 0] == 1,
op3[ref offset: 0] == 2, op3[ref offset: 0] changed
+   size:602 time:9868.835632 nonspec time:9884.134781 loops with known
iterations:0.470881 known strides:0.000000
+ - estimates for value 33554432 for param #3 npts[ref offset: 0]:
time_benefit: 109.299, size: 602

so the cost metric says that cloning will speed up the function by 0.1%
however good clonning oportunity seems happy:

+ - considering value 33554432 for param #3 npts, offset: 0 (caller_count: 2)
+     good_cloning_opportunity_p (time: 109.299, size: 602, freq_sum: 16.1818)
-> evaluation: 2937.97, threshold: 500

and we clone

+  Creating a specialized node of rfft/1.
+    adding an extra known scalar value &x for param #0 x
+    adding an extra known scalar value &trg for param #1 trg
+    adding an extra known scalar value &ibi for param #2 ibi
+    replacing param #0 x with const &x
+    replacing param #1 trg with const &trg
+    replacing param #2 ibi with const &ibi

[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
   Target Milestone|---                         |12.0

[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So nothing to see?  I guess our unit growth limit doesn't trigger because it's
a small (benchmark) unit?

Re: [Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[Jan Hubicka]

> So nothing to see?  I guess our unit growth limit doesn't trigger because it's
> a small (benchmark) unit?
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.

[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[hubicka at kam dot mff.cuni.cz]

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

--- Comment #6 from hubicka at kam dot mff.cuni.cz ---
> So nothing to see?  I guess our unit growth limit doesn't trigger because it's
> a small (benchmark) unit?
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.

[Bug tree-optimization/103195] [12 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[jamborm at gcc dot gnu.org]

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;

[Bug tree-optimization/103195] [12/13 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.0                        |12.2

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 12.1 is being released, retargeting bugs to GCC 12.2.

[Bug tree-optimization/103195] [12/13 Regression] tfft2 text grows by 70% with -Ofast since r12-5113-gd70ef65692fced7a

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think everything works as intended here - nothing to see.