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 tree-optimization]: [2 of 3]: Boolify compares & more


On Wed, Jul 20, 2011 at 3:31 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2011/7/20 Richard Guenther <richard.guenther@gmail.com>:
>> On Wed, Jul 20, 2011 at 3:05 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>> Hello,
>>>
>>> this is the revised version of the partial pre-approved patch for preserving
>>> type-casts from/to boolean-types. ?It fixes additionally the regression in
>>> tree-ssa/builtin-expect-5.c testcase, which was caused by fold_builtin_expect.
>>> Additionally there was a regression in gcc.dg/pr28685-1.c, which is fixed by
>>> the change in tree-ssa-forwprop.c's function simplify_bitwise_binary. ?This
>>> is just temporary necessary. ?As soon as we are boolifying comparisons in
>>> gimplifier, the pattern-matching in tree-ssa-reassoc will match for 2
>>> branched cases
>>> again and we can remove the hunk from forward-propagation again.
>>
>> Hm, if we can't apply this pieces without regressions we shouldn't. ?They
>> can then wait for the boolification patch.
>>
>> Can you explain the fold_builtin_expect change? ?I'm lost in the maze
>> of inner/inner_arg0/arg0 renaming game. ?It looks as if the patch only
>> moves stuff - but that can't possibly be the case. ?So, what's going on
>> there?
>
> Well, the issue is here that fold_builtin_expect checks here for a
> comparison. ?If this comparison was created initially with a
> boolean-type, the cast to 'long' will be in tree arg0 = (long)
> CMP-with-boolean-type, as we are preserving here casts from
> boolean-types (see the fold-const change). So we need to see through
> this casts to match the compare and call cases. So I moved this "see
> through" part before first pattern-match and introduced here a
> helper-variable inner_arg0 to avoid double while-loop. The "inner"
> variable might get invalid
> ...
> ? if (COMPARISON_CLASS_P (inner)
> ? ? ? && TREE_CODE (TREE_OPERAND (inner, 1)) == INTEGER_CST)
> ? ? inner = TREE_OPERAND (inner, 0);
> ...
>
> These are those "prefixed casts" you were asking in the other patch about.

I see.  So, if the builtin.c parts bootstrap & test ok then they are ok
to commit separately.

Thanks,
Richard.

> Regards,
> Kai
>


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