Refactor is_non_loop_exit_postdominating

That's a weird function in predicate analysis that currently looks like

/* Return true if BB1 is postdominating BB2 and BB1 is not a loop exit
   bb.  The loop exit bb check is simple and does not cover all cases.  */
static bool
is_non_loop_exit_postdominating (basic_block bb1, basic_block bb2)
{
  if (!dominated_by_p (CDI_POST_DOMINATORS, bb2, bb1))
    return false;
  if (single_pred_p (bb1) && !single_succ_p (bb2))
    return false;
  return true;
}

One can refactor this to

  return (dominated_by_p (CDI_POST_DOMINATORS, bb2, bb1)
          && !(single_pred_p (bb1) && !single_succ_p (bb2)));

Notable is that the comment refers to BB1 with respect to a loop
exit but the test seems to be written with an exit edge bb1 -> bb2
in mind.  None of the three callers are guaranteed to have bb1 and
bb2 connected directly with an edge.

The patch now introduces a is_loop_exit function and inlines
the post-dominance check which makes the find_control_equiv_block
case simpler because the post-dominance check can be elided.
It also avoids the double negation in compute_control_dep_chain
and makes it obvious this is the case where we do look at an edge.
For the main is_use_guarded API I chose to elide the loop exit
test, if the use block post-dominates the definition block of the
PHI node the use is always unconditional.  I don't quite understand
the loop exit special-casing of the remaining two uses though.

	* gimple-predicate-analysis.cc (is_loop_exit): Split out
	from ...
	(is_non_loop_exit_postdominating): ... here.  Remove after
	inlining ...
	(find_control_equiv_block): ... here.
	(compute_control_dep_chain): ... and here.
	(predicate::is_use_guarded): Do not excempt loop exits
	from short-cutting the case of the use post-dominating the
	PHI definition.

0 files changed, 0 insertions, 0 deletions