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: Jakub Jelinek <jakub at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Joseph Myers <joseph at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Feb 2015 17:06:38 +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> <CAFiYyc1XQ3jD5bWfjWfJZ+bRf7621XoA3q9oN-DYJxBQiH2bsw at mail dot gmail dot com> <54DB7BA4 dot 2030807 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Feb 11, 2015 at 08:56:20AM -0700, Jeff Law wrote:
> On 02/11/15 04:16, Richard Biener wrote:
> >>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).
> True, but I wanted to see if there was any impact, but thankfully there
> The fact that the C/C++ front-ends are doing most of the shortening now
> probably explains why the fix for 47477 only affected code generation for
> the Java front-end.
The C/C++ FEs are doing it only if it appears on a single statement though,
something fold can see at once.
If you rewrite it so that there are multiple vars holding the intermediate
values, they of course can't do that and it is a task for match.pd or
specialized pass to handle those.