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
On Thu, 6 Oct 2011, Kai Tietz wrote:
> That's not the hole story. The difference between TRUTH_(AND|OR)IF_EXPR
> and TRUTH_(AND|OR)_EXPR are, that for TRUTH_(AND|OR)IF_EXPR gimplifier
> creates a COND expression, but for TRUTH_(AND|OR)_EXPR it doesn't.
Yes, of course. That is what implements the short-circuit semantics. But
as Richard already mentioned I also don't understand why you do the
reassociation at that point. Why not simply rewrite ANDIF -> AND (when
possible, i.e. no sideeffects on arg1, and desirable, i.e. when
LOGICAL_OP_NON_SHORT_CIRCUIT, and simple_operand(arg1)) and let other
folders do reassociation? I ask because your comments states to
((W AND X) ANDIF Y) ANDIF Z
(W AND X) ANDIF (Y AND Z)
(under condition that Y and Z are simple operands).
In fact you don't check the form of arg0,0, i.e. the "W AND X" here.
Independend of that it doesn't make sense, because if Y and Z are easy
(simple and no side-effects), then "Y AND Z" is too, and therefore you
should transform this (if at all) into:
(W AND X) AND (Y AND Z)
at which point this association doesn't make sense anymore, as
((W AND X) AND Y) AND Z
is just as fine. So, the reassociation looks fishy at best, better get
rid of it? (which of the testcases breaks without it?)