This is the mail archive of the
mailing list for the GCC project.
Re: Reject tail calls that read from an escaped RESULT_DECL (PR90313)
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 09 Aug 2019 16:19:38 +0100
- Subject: Re: Reject tail calls that read from an escaped RESULT_DECL (PR90313)
- References: <firstname.lastname@example.org> <CAFiYyc2VevJBWYPYGB5qJ+Oo1ybysv3FqzQ9wwcK6bk8nzvwUw@mail.gmail.com> <20190809102245.GY2726@tucnak>
Jakub Jelinek <email@example.com> writes:
> On Fri, Aug 09, 2019 at 11:28:32AM +0200, Richard Biener wrote:
>> > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
> Can't we have a CLOBBER also for the RESULT_DECL var in some cases and
> on some paths and thus shouldn't we track the RESULT_DECL in
> in addition to the local vars (sure, tree-ssa-live.c would need to change
> the two spots where it tests VAR_P to VAR_P || == RESULT_DECL)?
Have you got an example of the kind of case in which that would cause
problems? If the RESULT_DECL isn't read by the tail call candidate,
then it should be OK for the candidate to write to and potentially
clobber the RESULT_DECL as it goes along, just like it would for
any other call.
In cases that we can currently turn into tail calls/recursion, either:
- the call assigns to the RESULT_DECL and the RESULT_DECL is live "at"
(= after) the call
- the call assigns to a local variable that is later copied (via a chain
of assignments) to RESULT_DECL. The RESULT_DECL isn't then live at/after
the call. (The chain of assignments must be complete assignments;
we don't allow RESULT_DECL to be written piecemeal.)