On Mon, Jun 27, 2011 at 12:58 PM, Kai Tietz <ktiet...@googlemail.com> wrote:
> 2011/6/27 Richard Guenther <richard.guent...@gmail.com>:
>> On Wed, Jun 22, 2011 at 3:09 PM, Kai Tietz <ktiet...@googlemail.com> wrote:
>>> Hello,
>>>
>>> This patch improves via type-sinking folding of binary and, or, and
>>> xor operations.
>>> First we do sinking also for compatible types with same precision, as
>>> those don't need to be preserved for these operations.
>>> Additional try to fold patterns (TYPE) X bin-op (Y CMP Z) and (TYPE) X
>>> bin-op !Y, if type of X is
>>> compatible to Y.
>>>
>>> ChangeLog gcc
>>>
>>> 2011-06-22 Kai Tietz <kti...@redhat.com>
>>>
>>> * tree-ssa-forwprop.c (simplify_bitwise_binary):
>>> Improve binary folding regarding casts.
>>>
>>>
>>> ChangeLog gcc/testsuite
>>>
>>> 2011-06-22 Kai Tietz <kti...@redhat.com>
>>>
>>> * gcc.dg/binop-notand1a.c: New test.
>>> * gcc.dg/binop-notand2a.c: New test.
>>> * gcc.dg/binop-notand3a.c: New test.
>>> * gcc.dg/binop-notand4a.c: New test.
>>> * gcc.dg/binop-notand5a.c: New test.
>>> * gcc.dg/binop-notand6a.c: New test.
>>>
>>> Bootstrapped and regression tested for all standard languages, Ada,
>>> and Obj-C++. Ok for apply?
>>
>> The first hunk is ok, the 2nd not - please don't use fold here. Also
>> your comment says what it tries to match, but not what it tries
>> to produce. So - what is the transformation you are trying to do?
>> The code is also two duplicates of exactly the same stuff.
>>
>> Btw, I see TRUTH_NOT_EXPR is still around, why's that so?
>>
>> Thanks,
>> Richard.
>
> Ok, I will sent first hunk as separate patch. The second hunk shall
> try to do simple simple folding like X & !X -> 0 (which is handled by
> fold-const, too). As special case we have here also (type) X & !X,
> and for case X & (type) !X. Later case can happen as soon as we
> preserve casts from boolean-type.
> I was thinking about implementing here the optimizations for all
> binary and/or/xor the foldings to constant directly in
> forward-propagate. This might be the better choice. Should I put this
> into a separate function in forward-propagation, or should I put this
> folding function into a different file?
The function is fine I think, but if you want X & !X -> 0 and similar
patterns then I don't see why you need to hand things to fold at all.
Just pattern-match the cases you are interested in. Eventually
add a helper function that can pattern-match !*X like
tree
match_unop_chain (enum tree_code code, tree name, tree stop_at
int *times)
{
*times = 0;
while (TREE_CODE (name) == SSA_NAME)
{
gimple def_stmt = SSA_NAME_DEF_STMT (name);
if (gimple_assign_rhs_code (def_stmt) != code)
break;
++*times;
name = gimple_assign_rhs1 (def_stmt);
if (name == stop_at)
break;
}
return name;
}
and use that, checking for even/odd *times. The above assumes
that code cancels itself out, like ~ or ! or -. Untested of course.
Richard.
>
> Regards,
> Kai
>
