This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 4/8 tree-optimization]: Bitwise or logic for fold_binary_loc.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]