From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-406646-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12839 invoked by alias); 14 Nov 2012 22:38:35 -0000
Received: (qmail 12774 invoked by uid 48); 14 Nov 2012 22:38:20 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90
Date: Wed, 14 Nov 2012 22:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-53346-4-pEOdp0sJoY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53346-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53346-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-11/txt/msg01308.txt.bz2


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

--- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-11-14 22:38:19 UTC ---
OK, similar loop in C looks like:
float a[10000];
float b[10000];
t()
{
  int mi = 0,i;
  for (i=0;i<1000;i++)
    if (a[i]<b[i])
      mi = i;
  return mi;
}
and the why we do not ifconvert at RTl level is that the condition is UNLE that
do not pass unordered_comparsion_operator.  This was noticed by Jakub in other
PR, we do not really need to test unorderedness here since expander knows how
to handle it.  So this was more by chance than by design. I am testing
Index: config/i386/i386.md
===================================================================
--- config/i386/i386.md (revision 193503)
+++ config/i386/i386.md (working copy)
@@ -964,7 +964,7 @@
        (compare:CC (match_operand:SDWIM 1 "nonimmediate_operand")
                    (match_operand:SDWIM 2 "<general_operand>")))
    (set (pc) (if_then_else
-              (match_operator 0 "ordered_comparison_operator"
+              (match_operator 0 "comparison_operator"
                [(reg:CC FLAGS_REG) (const_int 0)])
               (label_ref (match_operand 3))
               (pc)))]
@@ -982,7 +982,7 @@
        (compare:CC (match_operand:SWIM 2 "nonimmediate_operand")
                    (match_operand:SWIM 3 "<general_operand>")))
    (set (match_operand:QI 0 "register_operand")
-       (match_operator 1 "ordered_comparison_operator"
+       (match_operator 1 "comparison_operator"
          [(reg:CC FLAGS_REG) (const_int 0)]))]
   ""
 {
@@ -16120,7 +16120,7 @@

 (define_expand "mov<mode>cc"
   [(set (match_operand:SWIM 0 "register_operand")
-       (if_then_else:SWIM (match_operand 1 "ordered_comparison_operator")
+       (if_then_else:SWIM (match_operand 1 "comparison_operator")
                           (match_operand:SWIM 2 "<general_operand>")
                           (match_operand:SWIM 3 "<general_operand>")))]
   ""