Re: [PATCH 1/3] Introduce can_implement_as_sibling_call_p

[Jeff Law]

On 05/17/2016 04:01 PM, David Malcolm wrote:
This patch moves part of the logic for determining if tail
call optimizations are possible to a new helper function.
There are no functional changes.

expand_call is 1300 lines long, so there's arguably a
case for doing this on its own, but this change also
enables the followup patch.

The patch changes the logic from a big "if" with joined
|| clauses:

  if (first_problem ()
      ||second_problem ()
      /* ...etc... */
      ||final_problem ())
     try_tail_call = 0;

to a series of separate tests:

  if (first_problem ())
    return false;
  if (second_problem ())
    return false;
  /* ...etc... */
  if (final_problem ())
    return false;

I think the latter form has several advantages over the former:
- IMHO it's easier to read
- it makes it easy to put breakpoints on individual causes of failure
- it makes it easy to put specific error messages on individual causes
  of failure (as done in the followup patch).

Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu.

OK for trunk?

gcc/ChangeLog:
        * calls.c (expand_call): Move "Rest of purposes for tail call
        optimizations to fail" to...
        (can_implement_as_sibling_call_p): ...this new function, and
        split into multiple "if" statements.
This is good in and of itself as a refactoring/cleanup change.  That 
code has grown quite a list of "don't tailcall when ..." cases.

OK for the trunk.

jeff