Re: [patch tree-optimization]: [1 of 3]: Boolify compares & more

[Kai Tietz <ktietz70 at googlemail dot com>]

2011/7/8 Richard Guenther <richard.guenther@gmail.com>:
> On Fri, Jul 8, 2011 at 11:28 AM, Kai Tietz <ktietz70@googlemail.com> wrote
>> 2011/7/8 Richard Guenther <richard.guenther@gmail.com>:
>>> On Thu, Jul 7, 2011 at 6:06 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
>>>> Hello,
>>>>
>>>> This patch - first of series - adds to fold and some helper routines support
>>>> for one-bit precision bitwise folding and detection.
>>>> This patch is necessary for - next patch of series - boolification of
>>>> comparisons.
>>>>
>>>> Bootstrapped and regression tested for all standard-languages (plus
>>>> Ada and Obj-C++) on host x86_64-pc-linux-gnu.
>>>>
>>>> Ok for apply?
>>>
>>> Factoring out fold_truth_andor to a function should be done separately.
>>> A patch that does just that is pre-approved.
>>
>> Ok I will sent for this a separate patch. But in fact it makes just
>> sense together with the 1-bit precision bitwise support, too.
>
> No, it makes sense anyway to get rid of that goto. ?Note _only_ factoring
> out the function, not changing anything in it.

Done.

>>> Otherwise the patch globs too many changes and lacks reasoning.
>>> Why do we want to handle all this in fold when the boolification
>>> happens only after gimplification?
>>
>> We still rely on truth/bitwise folding on fold-const. ?Also we need to
>> handle this for passes, which are using fold_binary to optimize ?and
>> handle boolified operations - like tree-ssa-reassoc, of tree-vect*.
>> This support in fold-const is necessary when we are preserving casts
>> from/to boolean, as otherwise we don't fold bitwise-binary with
>> compares proper anymore. ?Additionally we have to take care that we
>> don't enter TRUTH_(AND|OR|XOR) expressions on boolified trees, as
>> otherwise tree-cfg will barf. Also we need to take care that types of
>> comparisons and TRUTH_NOT expressions are boolean one, as otherwise
>> again tree-cfg will detect incompatible types for those expressions.
>
> Sounds like many different things for many individual patches. ?Btw,
> I'd rather have the tree passes that rely on fold call a gimple specific
> wrapper where we can add such things (and also use gimple/SSA
> specific optimizations, like less strict typing), like
> gimple_fold_binary (....), see also my gimple folding proposal from
> earlier this year. http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01099.html

Well, this is for sure a good thing, but didn't solve the issues about
fold-const and 1-bit precision bitwise-operations. We need to handle
them in fold-const as otherwise even worse things are happening there.
 As fold-const happily decides that bitwise-binaries with comparisons
or thruth valued arguments getting transformed back into
TRUTH_(AND|OR|XOR)[IF]_EXPRs, which is indeed contra-productive on an
already gimplified tree.
For sure it would be better to avoid for such passes fold-const at all
and have instead a pure-ssa-named folding mechanism, but this is a
different story and not part of this patch.  Focus here is that we are
again able to do proper folding on boolified bitwise operations and to
provide to some passes the knowledge that a 1-bit precision bitwise
operation is an equivalent to a TRUTH_(AND|OR|XOR) and can be handled.

Regards,
Kai