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>")))]
""
