public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "steven at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use
Date: Sat, 05 Oct 2013 23:23:00 -0000	[thread overview]
Message-ID: <bug-58517-4-JG8hNpxx3j@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-58517-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

--- Comment #4 from Steven Bosscher <steven at gcc dot gnu.org> ---
So if I understand correctly, this is what happens (sorry, reading
LIPSy RTL is still just too unnatural to me! ;-))

before ifcvt-after-combine:
r147:=(r424>r178)
r190:=r423-r189
if (r147==0) goto L433
{r190:=(~r189)+r424; r147:=X}
L433:

after ifcvt-after-combine:
r147:=(r424>r189)
r190:=r423-r189
{r945:=(~r189)+r424; r147:=X}
r946:=r423-r189
r190:=(r147==0) ? r946:r945      // but r147 was clobbered!
r147:=(r190==0)
if (r147==0) goto L501


This is noce_try_cmove_arith:

  /* if (test) x = a + b; else x = c - d;
     => y = a + b;
        x = c - d;
        if (test)
          x = y;
  */

with "(test)" being clobbered by the assignment to "y" or "x" on the
code after the transformation has been applied.  noce_try_cmove_arith
does not expect that the arithmetic insns emitted to load vtrue or
vfalse into general operands may clobber the condition.  There should
be tests like this:

Index: ifcvt.c
===================================================================
--- ifcvt.c     (revision 203224)
+++ ifcvt.c     (working copy)
@@ -1573,6 +1573,8 @@ noce_try_cmove_arith (struct noce_if_info *if_info
                         optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn_a)));
       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
        return FALSE;
+      if (modified_in_p (if_info->cond, insn_a))
+       return FALSE;
     }
   else
     insn_cost = 0;
@@ -1584,6 +1586,8 @@ noce_try_cmove_arith (struct noce_if_info *if_info
                          optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn_b)));
       if (insn_cost == 0 || insn_cost > COSTS_N_INSNS (if_info->branch_cost))
         return FALSE;
+      if (modified_in_p (if_info->cond, insn_b))
+       return FALSE;
     }

   /* Possibly rearrange operands to make things come out more natural.  */



That's option 1 of comment #3.  Option 2 is only viable if the insn
computing "cond" is nearby (i.e. immediately above insn_a / insn_b),
otherwise it'll be necessary to solve a code motion dataflow problem.
Within one basic block that still would be doable (modified_between_p),
but I doubt it's worth the trouble.


  parent reply	other threads:[~2013-10-05 23:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-23 21:50 [Bug target/58517] New: [SH] wrong code with subc and movsicc (-mpretend-cmove) after ce2 olegendo at gcc dot gnu.org
2013-10-05 20:22 ` [Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and cc use olegendo at gcc dot gnu.org
2013-10-05 21:16 ` [Bug rtl-optimization/58517] icvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use olegendo at gcc dot gnu.org
2013-10-05 22:17 ` olegendo at gcc dot gnu.org
2013-10-05 23:23 ` steven at gcc dot gnu.org [this message]
2015-09-11 11:12 ` [Bug rtl-optimization/58517] ifcvt " ktkachov at gcc dot gnu.org
2023-06-02  1:38 ` pinskia at gcc dot gnu.org
2023-06-02  1:43 ` pinskia at gcc dot gnu.org
2023-06-02  1:44 ` pinskia at gcc dot gnu.org
2023-06-02  7:28 ` pinskia at gcc dot gnu.org
2023-06-02  7:57 ` pinskia at gcc dot gnu.org
2023-06-03  8:58 ` olegendo at gcc dot gnu.org
2023-06-03  9:02 ` pinskia at gcc dot gnu.org
2023-06-03 21:50 ` pinskia at gcc dot gnu.org
2023-06-03 22:18 ` pinskia at gcc dot gnu.org
2023-06-03 22:23 ` olegendo at gcc dot gnu.org
2023-06-03 22:59 ` pinskia at gcc dot gnu.org
2023-06-04  0:48 ` 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-58517-4-JG8hNpxx3j@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).