> ISTR the tailcall flag is only a hint and RTL expansion can decide to
> not tailcall based on targets. So to me it looks like a missed
> disqualification on the RTL expansion side.
That's IMO debatable: the GIMPLE tailcall optimization pass e.g. does:
/* Make sure the tail invocation of this function does not indirectly
refer to local variables. (Passing variables directly by value
is OK.) */
FOR_EACH_LOCAL_DECL (cfun, idx, var)
{
if (TREE_CODE (var) != PARM_DECL
&& auto_var_in_fn_p (var, cfun->decl)
&& may_be_aliased (var)
&& (ref_maybe_used_by_stmt_p (call, var)
|| call_may_clobber_ref_p (call, var)))
Do you want to replace it with something at the RTL level too? I don't think
that you can disqualify things at the RTL as easily as at the GIMPLE level.
> Or do we, besides from this very single spot, simply never tailcall at -O0
> and thus never hit this latent issue?
Presumably yes, tail calling is an optimization like the others.
> How does this change the debug experience at -O0 when GIMPLE thunks
> are used?
In Ada this doesn't change much since thunks have line debug info.
--
Eric Botcazou
