[RFC/SCCVN] Handle BIT_INSERT_EXPR in vn_nary_op_eq

[Marc Glisse]

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