[patch] Fix dangling references in thunks at -O0

[Richard Biener]

On Mon, Sep 14, 2020 at 10:36 AM Eric Botcazou <botcazou@adacore.com> wrote:
>
> > 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.

No, so you're right - validity analysis is split.  Still the cause you reference
comes from RTL expansion which means RTL expansion should possibly
do the disqualification here.  The question is what makes the case you
run into at -O0 impossible to trigger with -O1+?

Maybe we can also avoid this spilling at -O0?

> > 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.

Yeah, but the asm thunk tail-calls also at -O0.  I guess tail-calling is forced
here because gimple analysis sometimes would not mark the call.

> > 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.

I see, so as long as you then don't see extra frames it should be fine
with regard to debug info.

I'm not against the patch but let's leave it a bit for others to comment.

Richard.

> --
> Eric Botcazou
>
>