2011/10/11 Michael Matz <m...@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
