This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
2011/10/11 Michael Matz <matz@suse.de>:
> Hi,
>
> On Tue, 11 Oct 2011, Kai Tietz wrote:
>
>> So updated version for patch. ?It creates new simple_operand_p_2
>> function instead of modifying simple_operand_p function.
>
> FWIW: I also can't think of a nice short name for that predicate function
> :) ?One thing: move the test for TREE_SIDE_EFFECTS to that new function,
> then the if()s in fold_truth_andor become nicer. ?I think the code then is
> okay, but I can't approve. ?Just one remark about the comment:
>
>> + ? ? ?/* We don't want to pack more then two leafs to an non-IF AND/OR
>
> s/then/than/ s/an/a/
Ok, thanks
>> + ? ? ? ? expression.
>> + ? ? ? ? If tree-code of left-hand operand isn't an AND/OR-IF code and not
>> + ? ? ? ? equal to CODE, then we don't want to add right-hand operand.
>> + ? ? ? ? If the inner right-hand side of left-hand operand has side-effects,
>> + ? ? ? ? or isn't simple, then we can't add to it, as otherwise we might
>> + ? ? ? ? destroy if-sequence. ?*/
>
> 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);
>
>
> Ciao,
> Michael.
Well to use here binary form of operation seems to me misleading. 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)
Is the patch with those changes ok for apply?
Regards,
Kai