public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kyrill Tkachov <kyrylo.tkachov@arm.com>
To: Richard Biener <rguenther@suse.de>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH][match.pd] PR middle-end/66915 Restrict A - B -> A + (-B) to non-fixed-point types
Date: Thu, 23 Jul 2015 12:07:00 -0000	[thread overview]
Message-ID: <55B0CDC3.1040906@arm.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1507231314400.19642@zhemvz.fhfr.qr>


On 23/07/15 12:16, Richard Biener wrote:
> On Thu, 23 Jul 2015, Kyrill Tkachov wrote:
>
>> On 21/07/15 11:11, Richard Biener wrote:
>>> On Tue, 21 Jul 2015, Kyrill Tkachov wrote:
>>>
>>>> On 21/07/15 08:24, Richard Biener wrote:
>>>>> On Mon, 20 Jul 2015, Kyrill Tkachov wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> This patch fixes the PR in question which is a miscompilation of
>>>>>> gcc.dg/fixed-point/unary.c on arm.
>>>>>> It just restricts the A - B -> A + (-B) transformation when the type
>>>>>> is
>>>>>> fixed-point.
>>>>>>
>>>>>> This fixes the testcase for me.
>>>>>> Is this the right approach?
>>>>>>
>>>>>> Bootstrap and test on arm and x86 running.
>>>>>>
>>>>>> Ok if testing is clean?
>>>>> Ok, but I think the fold-const.c code has the same issue, no:
>>>>>
>>>>>          /* A - B -> A + (-B) if B is easily negatable.  */
>>>>>          if (negate_expr_p (arg1)
>>>>>              && !TYPE_OVERFLOW_SANITIZED (type)
>>>>>              && ((FLOAT_TYPE_P (type)
>>>>>                   /* Avoid this transformation if B is a positive
>>>>> REAL_CST.
>>>>> */
>>>>>                   && (TREE_CODE (arg1) != REAL_CST
>>>>>                       ||  REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1))))
>>>>>                  || INTEGRAL_TYPE_P (type)))
>>>>>            return fold_build2_loc (loc, PLUS_EXPR, type,
>>>>>                                fold_convert_loc (loc, type, arg0),
>>>>>                                fold_convert_loc (loc, type,
>>>>>                                                  negate_expr (arg1)));
>>>>>
>>>>> ah, no.  The above only applies to float-type and integral-types.
>>>>>
>>>>> Thus yes, your patch is ok.  Can you double-check the other pattern,
>>>>>
>>>>> /* -(A + B) -> (-B) - A.  */
>>>>> (simplify
>>>>>     (negate (plus:c @0 negate_expr_p@1))
>>>>>     (if (!HONOR_SIGN_DEPENDENT_ROUNDING (element_mode (type))
>>>>>          && !HONOR_SIGNED_ZEROS (element_mode (type)))
>>>>>      (minus (negate @1) @0)))
>>>>>
>>>>> ?
>>>> Thanks, committed with r226028.
>>>> I can add (FLOAT_TYPE_P (type) || INTEGRAL_TYPE_P (type)) to the
>>>> condition.
>>>> That would more closely mirror the original logic, right?
>>>> That passes x86_64 bootstrap and aarch64 testing looks ok.
>>> Yeah, that works for me, too.
>> How about this patch then?
>> Bootstrapped and tested on x86_64 and aarch64.
> Hmm.  The code already pretty much matches the one in fold-const.c.
>
> So what's the actual issue with fixed-point types and
> -(A + B) -> -B - A iff negate_expr_p says that B can be
> safely negated?
>
> That is, can you add a testcase that fails without the patch?

I don't have such a testcase.
If negate_expr_p does what we want here, then I suppose it's redundant
and I withdraw the patch.
I'm not very familiar with the fold-const.c code...

Kyrill

>
> Thanks
> Richard.
>

      reply	other threads:[~2015-07-23 11:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-20 14:32 Kyrill Tkachov
2015-07-21  9:09 ` Richard Biener
2015-07-21  9:26   ` Kyrill Tkachov
2015-07-21 10:23     ` Richard Biener
2015-07-23  9:21       ` Kyrill Tkachov
2015-07-23 11:19         ` Richard Biener
2015-07-23 12:07           ` Kyrill Tkachov [this message]

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=55B0CDC3.1040906@arm.com \
    --to=kyrylo.tkachov@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /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).