From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5FC493858407 for ; Thu, 9 Dec 2021 14:04:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5FC493858407 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-496-xdkaXIdtNTqMLngo7rpu1A-1; Thu, 09 Dec 2021 09:04:39 -0500 X-MC-Unique: xdkaXIdtNTqMLngo7rpu1A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7E77F1018721; Thu, 9 Dec 2021 14:04:38 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.123]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E87BE60BF1; Thu, 9 Dec 2021 14:04:35 +0000 (UTC) From: Florian Weimer To: Marc Feeley Cc: Segher Boessenkool , Jeff Law , gcc-help@gcc.gnu.org, "Lucier, Bradley J" , Bradley Lucier Subject: Re: CALL_EXPR_MUST_TAIL_CALL and LLVM's musttail References: <4cf670fd-e869-0af0-9e55-85c9d8df8882@math.purdue.edu> <0134ccc5-f432-3776-ec13-fa46091b4b1c@gmail.com> <20211209000737.GS614@gate.crashing.org> <87tufigi5s.fsf@oldenburg.str.redhat.com> Date: Thu, 09 Dec 2021 15:04:34 +0100 In-Reply-To: (Marc Feeley's message of "Thu, 9 Dec 2021 08:30:56 -0500") Message-ID: <875yrxho25.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2021 14:04:42 -0000 * Marc Feeley: > [Marc Feeley here, the author of the Gambit Scheme compiler that generate= s the code which would benefit from tail-calls] > > What is needed (for Gambit) is a way for the programmer to express in > the source code that the tail-call is known to be optimizable, i.e. it > does not violate any of the tail-calling constraints, such as all > local variables are dead (including those whose address was taken with > =E2=80=9C&var=E2=80=9D) at the moment of the call. Are you presently using scopes for that? See the different between f3 and f3_tail on x86-64: void f1 (int *); int f2 (int *); int f3 (void) { int i; f1 (&i); return f2 (i); } int f3_tail (void) { int i; { int i0; f1 (&i0); i =3D i0; } return f2 (i); } If the life-time of the variables whose address has been taken has ended at the time of the call in a tail position, I expect GCC to turn it into a tail call (subject to the other constraints mentioned). Thanks, Florian