public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "mikpe at it dot uu dot se" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/40987] Wrong optimization with if-conversion Date: Sat, 19 Sep 2009 16:57:00 -0000 [thread overview] Message-ID: <20090919165728.15532.qmail@sourceware.org> (raw) In-Reply-To: <bug-40987-18027@http.gcc.gnu.org/bugzilla/> ------- Comment #9 from mikpe at it dot uu dot se 2009-09-19 16:57 ------- Seems like an if-conversion bug, in particular noce_try_store_flag_constants() appears to break on HWI32 platforms when long long literals are involved. In this test case, noce_t_s_f_c() is invoked with an IF where a (the false value) and b (the true value) are both DImode CONST_INTs. a is zero. b is stored as 0x80000000, which is truncated but sign-extends to the correct value. noce_t_s_f_c() then computes a subtraction and some log2() on these truncated values, and selects the second code generation template "x = (test != 0) << 3;". The code becomes (from the ce1 dump file): (insn 27 8 28 2 pr40987.c:4 (parallel [ (set (reg:DI 62) (sign_extend:DI (reg/v:SI 60 [ arg ]))) (clobber (reg:CC 17 flags)) (clobber (scratch:SI)) ]) 90 {*extendsidi2_1} (nil)) (insn 28 27 29 2 pr40987.c:4 (parallel [ (set (reg/v:DI 58 [ val ]) (lshiftrt:DI (reg:DI 62) (const_int 63 [0x3f]))) (clobber (reg:CC 17 flags)) ]) 394 {*lshrdi3_1} (nil)) # since this is a logical downshift, it produces 0 or 1 from the sign bit (insn 29 28 17 2 pr40987.c:4 (parallel [ (set (reg/v:DI 58 [ val ]) (ashift:DI (reg/v:DI 58 [ val ]) (const_int 31 [0x1f]))) (clobber (reg:CC 17 flags)) ]) 356 {*ashldi3_1} (nil)) # which is shifted up to produce 0 or 0x80000000, the high 32 bits are lost All gcc-4.x releases have this bug. It does not trigger in gcc-3.4.6. There it seems that the true/false values are swapped compared to 4.x, and a test near the top of noce_t_s_f_c() causes it to bail out and not perform the conversion. (The test looks the same in 4.x, but the IF-operands are swapped so it does not bail.) I don't know if this code can be fixed to handle longer-than-HWI literals. The simplest solution might be to just detect the situation and bail out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40987
next prev parent reply other threads:[~2009-09-19 16:57 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-08-06 14:06 [Bug c/40987] New: " thomas at coware dot com 2009-08-06 14:58 ` [Bug c/40987] " rguenth at gcc dot gnu dot org 2009-08-06 15:26 ` thomas at coware dot com 2009-08-06 15:59 ` mikpe at it dot uu dot se 2009-08-06 19:25 ` thomas at coware dot com 2009-08-06 22:12 ` steven at gcc dot gnu dot org 2009-08-06 22:13 ` steven at gcc dot gnu dot org 2009-08-07 7:38 ` thomas at coware dot com 2009-08-07 12:10 ` [Bug rtl-optimization/40987] " rguenth at gcc dot gnu dot org 2009-09-19 16:57 ` mikpe at it dot uu dot se [this message] 2009-09-24 14:39 ` mikpe at it dot uu dot se 2009-09-26 10:18 ` steven at gcc dot gnu dot org [not found] <bug-40987-4@http.gcc.gnu.org/bugzilla/> 2012-01-21 21:33 ` 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=20090919165728.15532.qmail@sourceware.org \ --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).