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 tree-optimization/99078] [8/9/10/11 Regression] Optimizer moves struct initialization into loop
Date: Fri, 12 Feb 2021 08:27:31 +0000	[thread overview]
Message-ID: <bug-99078-4-HribykN0CA@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99078-4@http.gcc.gnu.org/bugzilla/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-02-12
      Known to work|                            |6.5.0
            Summary|Optimizer moves struct      |[8/9/10/11 Regression]
                   |initialization into loop    |Optimizer moves struct
                   |                            |initialization into loop
     Ever confirmed|0                           |1
          Component|c++                         |tree-optimization
           Keywords|                            |missed-optimization
      Known to fail|                            |11.0, 7.5.0
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P2
                 CC|                            |jamborm at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |8.5

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  It is SRA that with total scalarization re-materializes 's' before
the aggregate use it cannot transform (*dest_106 = s).  Looks like quite
pointless in any case (removing one set of inits just to re-emit them for
the single remat case), maybe there's no costing involved at all?

There isn't really sth like a pass that hoists stores so undoing this
is really hard which means better avoid total scalarization of sth
where rematerialization in a bigger loop depth is required?


--- t.C.117t.cplxlower1 2021-02-12 09:17:00.278704232 +0100
+++ t.C.118t.sra        2021-02-12 09:17:00.278704232 +0100
...
@@ -10,26 +58,46 @@

   <bb 2> [local count: 118111600]:
   s = {};
-  s.c[1] = 1;
-  s.c[2] = 2;
-  s.c[3] = 3;
-  s.c[4] = 4;
-  s.c[5] = 5;
-  s.c[6] = 6;
-  s.c[8] = 8;
-  s.c[9] = 9;
-  s.c[10] = 10;
-  s.c[11] = 11;
-  s.c[12] = 12;
-  s.c[13] = 13;
-  s.c[14] = 14;
-  s.c[16] = 16;
-  s.c[17] = 17;
-  s.c[18] = 18;
-  s.c[19] = 19;
-  s.c[20] = 20;
-  s.c[21] = 21;
-  s.c[22] = 22;
+  s$c$1_12 = 0;
+  s$c$2_5 = 0;
+  s$c$3_4 = 0;
+  s$c$4_101 = 0;
+  s$c$5_100 = 0;
+  s$c$6_99 = 0;
+  s$c$8_116 = 0;
+  s$c$9_119 = 0;
+  s$c$10_121 = 0;
+  s$c$11_124 = 0;
+  s$c$12_126 = 0;
+  s$c$13_129 = 0;
+  s$c$14_131 = 0;
+  s$c$16_64 = 0;
+  s$c$17_66 = 0;
+  s$c$18_69 = 0;
+  s$c$19_71 = 0;
+  s$c$20_74 = 0;
+  s$c$21_76 = 0;
+  s$c$22_79 = 0;
+  s$c$1_81 = 1;
+  s$c$2_84 = 2;
+  s$c$3_86 = 3;
+  s$c$4_89 = 4;
+  s$c$5_91 = 5;
+  s$c$6_94 = 6;
+  s$c$8_96 = 8;
+  s$c$9_29 = 9;
+  s$c$10_31 = 10;
+  s$c$11_34 = 11;
+  s$c$12_36 = 12;
+  s$c$13_39 = 13;
+  s$c$14_41 = 14;
+  s$c$16_44 = 16;
+  s$c$17_46 = 17;
+  s$c$18_49 = 18;
+  s$c$19_51 = 19;
+  s$c$20_54 = 20;
+  s$c$21_56 = 21;
+  s$c$22_59 = 22;
   count_104 = count_20(D) + 4294967295;
   if (count_20(D) != 0)
     goto <bb 3>; [89.00%]
@@ -40,6 +108,26 @@
   # dest_106 = PHI <dest_19(D)(2), dest_25(3)>
   # count_114 = PHI <count_104(2), count_23(3)>
   dest_25 = dest_106 + 24;
+  s.c[1] = s$c$1_81;
+  s.c[2] = s$c$2_84;
+  s.c[3] = s$c$3_86;
+  s.c[4] = s$c$4_89;
+  s.c[5] = s$c$5_91;
+  s.c[6] = s$c$6_94;
+  s.c[8] = s$c$8_96;
+  s.c[9] = s$c$9_29;
+  s.c[10] = s$c$10_31;
+  s.c[11] = s$c$11_34;
+  s.c[12] = s$c$12_36;
+  s.c[13] = s$c$13_39;
+  s.c[14] = s$c$14_41;
+  s.c[16] = s$c$16_44;
+  s.c[17] = s$c$17_46;
+  s.c[18] = s$c$18_49;
+  s.c[19] = s$c$19_51;
+  s.c[20] = s$c$20_54;
+  s.c[21] = s$c$21_56;
+  s.c[22] = s$c$22_59;
   *dest_106 = s;
   count_23 = count_114 + 4294967295;
   if (count_114 != 0)

  reply	other threads:[~2021-02-12  8:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-12  1:17 [Bug c++/99078] New: " magiblot at hotmail dot com
2021-02-12  8:27 ` rguenth at gcc dot gnu.org [this message]
2021-05-14  9:54 ` [Bug tree-optimization/99078] [9/10/11/12 Regression] " jakub at gcc dot gnu.org
2021-06-01  8:19 ` rguenth at gcc dot gnu.org
2022-05-27  9:44 ` [Bug tree-optimization/99078] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:43 ` jakub at gcc dot gnu.org
2023-07-07 10:39 ` [Bug tree-optimization/99078] [11/12/13/14 " rguenth at gcc dot gnu.org
2024-02-21  4:42 ` pinskia 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-99078-4-HribykN0CA@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).