From: Jeff Law <law@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing
Date: Wed, 11 Feb 2015 06:43:00 -0000 [thread overview]
Message-ID: <54DAFA05.5050804@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1502031204440.11494@digraph.polyomino.org.uk>
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
next prev parent reply other threads:[~2015-02-11 6:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-31 8:53 Jeff Law
2015-02-01 0:47 ` Joseph Myers
2015-02-01 5:46 ` Jeff Law
2015-02-02 8:57 ` Richard Biener
2015-02-02 18:32 ` Jeff Law
2015-02-03 11:39 ` Richard Biener
2015-02-09 7:15 ` Jeff Law
2015-02-09 13:42 ` Richard Biener
2015-02-09 18:33 ` Jeff Law
2015-02-02 16:59 ` Joseph Myers
2015-02-02 18:04 ` Jeff Law
2015-02-03 7:20 ` Jeff Law
2015-02-03 12:23 ` Joseph Myers
2015-02-08 7:43 ` Jeff Law
2015-02-11 6:43 ` Jeff Law [this message]
2015-02-11 11:16 ` Richard Biener
2015-02-11 15:56 ` Jeff Law
2015-02-11 16:06 ` Jakub Jelinek
2015-02-11 17:13 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DAFA05.5050804@redhat.com \
--to=law@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).