Hi,
A address canonicalization interface was introduced by my original patch to 
PR69052.  The interface sorts sub-parts in an address expression based on 
precedences defined by function commutative_operand_precedence.  It also 
assumes that all CONST_INT sub-parts are at the end of vector after sorting.  
But this is not always true because commutative_operand_precedence sets the 
same precedence to both CONST_INT and CONST_WIDE_INT.  The patch could be 
broken in cases which have CONST_WIDE_INT sorted after CONST_INT.  Even though 
I don't think we can really run into such complicated case, I worked out a 
patch forcing CONST_INT to lower precedence than CONST_WIDE_INT, so that for 
sure it will be sorted after all other kinds sub-parts.

This is an obvious change.  Bootstrap&test on x86_64, bootstrap&test on 
AArch64.  Is it OK for this stage?

Thanks,
bin

2016-03-04  Bin Cheng  <bin.ch...@arm.com>

        PR rtl-optimization/69052
        * loop-invariant.c (compare_address_parts): Force CONST_INT to lower
        precedence than CONST_WIDE_INT.
diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
index dcbe932..27a1815 100644
--- a/gcc/loop-invariant.c
+++ b/gcc/loop-invariant.c
@@ -820,6 +820,12 @@ compare_address_parts (const void *x, const void *y)
   int px = commutative_operand_precedence (*rx);
   int py = commutative_operand_precedence (*ry);
 
+  /* Put CONST_INT behind CONST_WIDE_INT.  */
+  if (CONST_INT_P (*rx) && CONST_WIDE_INT_P (*ry))
+    return 1;
+  else if (CONST_WIDE_INT_P (*rx) && CONST_INT_P (*ry))
+    return -1;
+
   return (py - px);
 }
 

Reply via email to