On Wed, Feb 11, 2015 at 7:43 AM, Jeff Law <l...@redhat.com> wrote: > 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.
The c-family frontends perform this kind of narrowing already anyway (via the shorten_* stuff which is misplaced there and should be done elsewhere for all frontends - thus in match.pd, thanks for starting that). Richard. > jeff >
