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
