From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
 by sourceware.org (Postfix) with ESMTP id 97A193858411
 for <gcc-help@gcc.gnu.org>; Thu,  9 Dec 2021 00:08:39 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 97A193858411
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=kernel.crashing.org
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=kernel.crashing.org
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])
 by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 1B907cCL017415;
 Wed, 8 Dec 2021 18:07:38 -0600
Received: (from segher@localhost)
 by gate.crashing.org (8.14.1/8.14.1/Submit) id 1B907bYx017414;
 Wed, 8 Dec 2021 18:07:37 -0600
X-Authentication-Warning: gate.crashing.org: segher set sender to
 segher@kernel.crashing.org using -f
Date: Wed, 8 Dec 2021 18:07:37 -0600
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: Bradley Lucier <lucier@math.purdue.edu>, gcc-help@gcc.gnu.org,
 Marc Feeley <feeley@iro.umontreal.ca>, lucier@purdue.edu
Subject: Re: CALL_EXPR_MUST_TAIL_CALL and LLVM's musttail
Message-ID: <20211209000737.GS614@gate.crashing.org>
References: <4cf670fd-e869-0af0-9e55-85c9d8df8882@math.purdue.edu>
 <0134ccc5-f432-3776-ec13-fa46091b4b1c@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0134ccc5-f432-3776-ec13-fa46091b4b1c@gmail.com>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL,
 KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS,
 TXREP autolearn=no 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 <gcc-help.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2021 00:08:41 -0000

On Wed, Dec 08, 2021 at 04:17:33PM -0700, Jeff Law via Gcc-help wrote:
> On 12/7/2021 3:38 PM, Bradley Lucier via Gcc-help wrote:
> >So I've been investigating whether gcc's -foptimize-sibling-calls 
> >option (for which I've found very little documentation) might produce 
> >similar results.
> The option has been around for probably 20+ years at this point, you 
> just might not have been aware of it.  They try, but do not guarantee 
> tail call optimization.   They have all kinds of checks that might cause 
> any particular call site to be rejected for tail call elimination.  It's 
> enabled by default at O2 or higher.

(Including -Os.)

GCC will never not do a tail call if it knows any way to do it.  A very
low-tech way of checking if all your threaded code words got proper
tail calls is to simply look if there are any "return" instructions in
the generated machine code :-)


Segher