Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

[Jeff Law <law at redhat dot com>]

On 02/03/15 05:23, Joseph Myers wrote:
> > +	 && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))
> > +	 && TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE (@1))
> > +	 && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0)))
> > +      (convert (bit_and (inner_op @0 @1) (convert @3))))))
>
> I still don't think this is safe.  Suppose @0 and @1 are -128 in type
> int8_t and @3 is 128 in a wider type and the operation is AND.  Then the
> original expression has result 128.  But if you convert @3 to int8_t you
> get -128 and this would result in -128 from the simplified expression.
Looking at this again, @3 is being converted to the wrong type, plain 
and simple.  I should never write code while heavily medicated.  I 
suspect that combined with trying to work around the genmatch bug Richi 
just fixed sent me down a totally wrong path.

I think the way to go is to always convert the inner operands to an 
unsigned type.  In fact, everything except the outer convert should be 
using an unsigned type of the same size/precision as @0's type.  The 
outer convert should, of course, be the final type.

That avoids all the concerns about sign bit propagation from the narrow 
type into the wider final type.

Application of this pattern (and the one I posted for 47477) is a 
concern for targets that don't do sub-word arithmetic/logicals.  But I 
just did a sniff test of one such target (v850-elf because it was handy) 
and I couldn't spot a change in the end code using both the 47477 patch 
and my WIP patch for this BZ.

jeff