[patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

[Kai Tietz]

2011/10/12 Michael Matz <matz@suse.de>:
> Hi,
>
> On Wed, 12 Oct 2011, Kai Tietz wrote:
>
>> > And I think it could use some overview of the transformation done like in
>> > the initial patch, ala:
>> >
>> > "Transform ((A && B) && C) into (A && (B & C))."
>> >
>> > and
>> >
>> > "Or (A && B) into (A & B)." for this part:
>> >
>> > +     /* Needed for sequence points to handle trappings, and side-effects.  */
>> > +     else if (simple_operand_p_2 (arg0))
>> > +       return fold_build2_loc (loc, ncode, type, arg0, arg1);
>>
>> Well to use here binary form of operation seems to me misleading.
>
> Hmm?  What do you mean?  Both operations are binary.  ANDIF is '&&', AND
> is '&'.  In fold-const.c comments we usually use the C notations of the
> operations.

See TRUTH_AND_EXPR is in C-notation && and TRUTH_ANDIF_EXPR is also
&&.  The transcription to binary & is done in gimplifier.  Btw I just
noticed that by this patch a latent bug in gimplifier about
boolification for TRUTH_NOT_EXPR/TRUTH_AND/OR... is present.
On Fortran there are different boolean-kinds types with different
precision.  This makes them incompatible to eachother in gimple (as
useless_type_conversion_p returns for them false).  For gimplier needs
to ensure that operands for those TRUTH_... expression met a
compatible type of final expression type.

I will sent a patch for this as soon I completed regression-testing for it.

>> It is right that the non-IF AND/OR has finally the same behavior as the
>> binary form in gimple.  Nevertheless it isn't the same on AST level. But
>> sure I can Add comments for operations like (A OR/AND-IF B) OR/AND-IF C
>> -> (A OR/AND-IF (B OR/AND C and A OR/AND-IF C -> (A OR/AND C)
>
> Too much noise, leave out the || variant, and just say once "Same for ||."
>
>
> Ciao,
> Michael.

Cheers,
Kai