This is the mail archive of the
mailing list for the GCC project.
Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Feb 2015 12:16:50 +0100
- Subject: Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing
- Authentication-results: sourceware.org; auth=none
- References: <54CC560B dot 8080200 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1502010039210 dot 23456 at digraph dot polyomino dot org dot uk> <54CDBDC6 dot 3050000 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1502021655230 dot 20528 at digraph dot polyomino dot org dot uk> <54CFBC2E dot 2040602 at redhat dot com> <54D076BC dot 9080504 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1502031204440 dot 11494 at digraph dot polyomino dot org dot uk> <54DAFA05 dot 5050804 at redhat dot com>
On Wed, Feb 11, 2015 at 7:43 AM, Jeff Law <email@example.com> wrote:
> On 02/03/15 05:23, Joseph Myers wrote:
>>> + && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE
>>> + && TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE
>>> + && 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).