[RFC/SCCVN] Handle BIT_INSERT_EXPR in vn_nary_op_eq

Andrew Pinski pinskia@gmail.com
Thu Jul 13 01:19:00 GMT 2017


Hi,
  Unlike most other expressions, BIT_INSERT_EXPR has an implicit
operand of the precision/size of the second operand.  This means if we
have an integer constant for the second operand and that compares to
the same constant value, vn_nary_op_eq would return that these two
expressions are the same.  But in the case I was looking into the
integer constants had different types, one with 1 bit precision and
the other with 2 bit precision which means the BIT_INSERT_EXPR were
not equal at all.

This patches the problem by checking to see if BIT_INSERT_EXPR's
operand 1's (second operand) type  has different precision to return
false.

Is this the correct location or should we be checking for this
differently?  If this is the correct location, is the patch ok?
Bootstrapped and tested on aarch64-linux-gnu with no regressions (and
also tested with a few extra patches to expose BIT_INSERT_EXPR).

Thanks,
Andrew Pinski

ChangeLog:
* tree-ssa-sccvn.c (vn_nary_op_eq): Check BIT_INSERT_EXPR's operand 1
to see if the types precision matches.
-------------- next part --------------
Index: tree-ssa-sccvn.c
===================================================================
--- tree-ssa-sccvn.c	(revision 250159)
+++ tree-ssa-sccvn.c	(working copy)
@@ -2636,6 +2636,14 @@ vn_nary_op_eq (const_vn_nary_op_t const
     if (!expressions_equal_p (vno1->op[i], vno2->op[i]))
       return false;
 
+  /* BIT_INSERT_EXPR has an implict operand as the type precision
+     of op1.  Need to check to make sure they are the same.  */
+  if (vno1->opcode == BIT_INSERT_EXPR)
+    if (INTEGRAL_TYPE_P (TREE_TYPE (vno1->op[0]))
+	&& TYPE_PRECISION (TREE_TYPE (vno1->op[1]))
+	    != TYPE_PRECISION (TREE_TYPE (vno2->op[1])))
+      return false;
+
   return true;
 }
 


More information about the Gcc-patches mailing list