[patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs
Thu Oct 6 15:38:00 GMT 2011
2011/10/6 Michael Matz <firstname.lastname@example.org>:
> 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
Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and
therefore it isn't transformed into and AND.
> ((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?)
None. I had this implemented first. But Richard was concerned about
making non-IF conditions too long. I understand that point that it
might not that good to always modify unconditionally to AND/OR chain.
if (a1 && a2 && a3 && .... && a100) return 1;
would be packed by this patch into 50 branches. If we would modify
all of them into AND, then we would calculate for all 100 values the
result, even if the first a1 is zero. This doesn't improve speed
But you are right, that from the point of reassociation optimization
it could be in some cases more profitable to have packed all elements
into on AND-chain.
More information about the Gcc-patches