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)
next prev parent 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: linkBe 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).