From: Richard Guenther <richard.guenther@gmail.com>
To: Kai Tietz <ktietz70@googlemail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch 4/8 tree-optimization]: Bitwise or logic for fold_binary_loc.
Date: Wed, 13 Jul 2011 11:09:00 -0000 [thread overview]
Message-ID: <CAFiYyc2qGFZqR-bntE0hghtGXkit0cZALE7eFsaKqJtS1sEW7Q@mail.gmail.com> (raw)
In-Reply-To: <CAEwic4bf+T8VvotahOs53rviRQXXD8ZYY9_7T+fLTE8aDU0O9Q@mail.gmail.com>
On Wed, Jul 13, 2011 at 12:39 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2011/7/13 Richard Guenther <richard.guenther@gmail.com>:
>> On Wed, Jul 13, 2011 at 9:33 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>> Hello,
>>>
>>> This patch adds support to fold_binary_loc for one-bit precision
>>> typed bitwise-or expression.
>>
>> Seems to be a fallout of the missing TRUTH_NOT conversion as well.
>>
>>> ChangeLog
>>>
>>> 2011-07-13 Kai Tietz <ktietz@redhat.com>
>>>
>>> * fold-const.c (fold_binary_loc): Add
>>> support for one-bit bitwise-or optimizeation.
>>>
>>> Bootstrapped and regression tested with prior patches of this series
>>> for x86_64-pc-linux-gnu.
>>> Ok for apply?
>>>
>>> Regards,
>>> Kai
>>>
>>> Index: gcc/gcc/fold-const.c
>>> ===================================================================
>>> --- gcc.orig/gcc/fold-const.c 2011-07-13 08:23:29.000000000 +0200
>>> +++ gcc/gcc/fold-const.c 2011-07-13 08:59:04.011620200 +0200
>>> @@ -10688,6 +10688,52 @@ fold_binary_loc (location_t loc,
>>> return omit_one_operand_loc (loc, type, t1, arg0);
>>> }
>>>
>>> + if (TYPE_PRECISION (type) == 1 && INTEGRAL_TYPE_P (type))
>>> + {
>>> + /* If arg0 is constant zero, drop it. */
>>> + if (TREE_CODE (arg0) == INTEGER_CST && integer_zerop (arg0))
>>> + return non_lvalue_loc (loc, fold_convert_loc (loc, type, arg1));
>>> + if (TREE_CODE (arg0) == INTEGER_CST && ! integer_zerop (arg0))
>>> + return omit_one_operand_loc (loc, type, arg0, arg1);
>>> +
>>> + /* !X | X is always true. ~X | X is always true. */
>>> + if ((TREE_CODE (arg0) == TRUTH_NOT_EXPR
>>> + || TREE_CODE (arg0) == BIT_NOT_EXPR)
>>> + && operand_equal_p (TREE_OPERAND (arg0, 0), arg1, 0))
>>> + return omit_one_operand_loc (loc, type, integer_one_node, arg1);
>>> + /* X | !X is always true. X | ~X is always true. */
>>> + if ((TREE_CODE (arg1) == TRUTH_NOT_EXPR
>>> + || TREE_CODE (arg1) == BIT_NOT_EXPR)
>>> + && operand_equal_p (arg0, TREE_OPERAND (arg1, 0), 0))
>>> + return omit_one_operand_loc (loc, type, integer_one_node, arg0);
>>> +
>>> + /* (X & !Y) | (!X & Y) is X ^ Y */
>>> + if (TREE_CODE (arg0) == BIT_AND_EXPR
>>> + && TREE_CODE (arg1) == BIT_AND_EXPR)
>>> + {
>>> + tree a0, a1, l0, l1, n0, n1;
>>> +
>>> + a0 = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 0));
>>> + a1 = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 1));
>>> +
>>> + l0 = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 0));
>>> + l1 = fold_convert_loc (loc, type, TREE_OPERAND (arg0, 1));
>>> +
>>> + n0 = fold_build1_loc (loc, TRUTH_NOT_EXPR, type, l0);
>>> + n1 = fold_build1_loc (loc, TRUTH_NOT_EXPR, type, l1);
>>> +
>>> + if ((operand_equal_p (n0, a0, 0)
>>> + && operand_equal_p (n1, a1, 0))
>>> + || (operand_equal_p (n0, a1, 0)
>>> + && operand_equal_p (n1, a0, 0)))
>>> + return fold_build2_loc (loc, BIT_XOR_EXPR, type, l0, n1);
>>> + }
>>> +
>>> + tem = fold_truth_andor (loc, code, type, arg0, arg1, op0, op1);
>>> + if (tem)
>>> + return tem;
>>> + }
>>> +
>>> /* Canonicalize (X & C1) | C2. */
>>> if (TREE_CODE (arg0) == BIT_AND_EXPR
>>> && TREE_CODE (arg1) == INTEGER_CST
>
> Well, I wouldn't call it fallout. As by this we are able to handle
> things like ~(X >= B) and see that it can be converted to X < B. The
> point here is that we avoid that fold re-introduces here the TRUTH
> variants for the bitwise ones (for sure some parts are redudant and
> might be something to be factored out like we did for truth_andor
> function). Also we catch by this patterns like ~X op ~Y and convert
> them to ~(X op Y), which is just valid for one-bit precision typed X
> and Y.
> As in general !x is not the same as ~x, beside x has one-bit precision
> integeral type.
>
> I will adjust patches so, that for one-bit precision type we alway
> use here instead BIT_NOT_EXPR (instead of TRUTH_NOT). This is
> reasonable.
Sorry, but no.
fold-const.c should not look at 1-bitness at all. fold-const.c should
special-case BOOLEAN_TYPEs - and it does that already.
This patch series makes me think that it is premature given that
on gimple we still mix TRUTH_NOT_EXPR and BIT_*_EXPRs.
Richard.
prev parent reply other threads:[~2011-07-13 11:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-13 7:35 Kai Tietz
2011-07-13 10:31 ` Richard Guenther
2011-07-13 10:48 ` Kai Tietz
2011-07-13 11:09 ` Richard Guenther [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=CAFiYyc2qGFZqR-bntE0hghtGXkit0cZALE7eFsaKqJtS1sEW7Q@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=ktietz70@googlemail.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).