On Wed, 12 Jul 2017, Andrew Pinski wrote:
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.
Hello,
since BIT_INSERT_EXPR is implicitly an expression with 4 arguments, it
makes sense that we may need a few such special cases. But shouldn't the
hash function be in sync with the equality comparator? Does
operand_equal_p need the same?
--
Marc Glisse
