[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