This is the mail archive of the
mailing list for the GCC project.
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
2011/10/12 Michael Matz <firstname.lastname@example.org>:
> 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
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 ||."