From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by sourceware.org (Postfix) with ESMTPS id 154E4390D9B7 for ; Tue, 4 Jun 2024 13:49:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 154E4390D9B7 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 154E4390D9B7 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717508947; cv=none; b=JUe88j4xdQ01wT11fbhtKKCv/VHU/3mVQGV0LW7+nW4af8iM0ZhoBkGvaZf6RcNKBRxxCSJw3Fsn7yAlW49cMBPL2qgzQs0ntgOvBG7+gBRccLTEMvj92ITgySw/MpppfW2aaPr7DQzcQ6McgOWkHxnhZX8x3ucnTAJXvVg1R/4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717508947; c=relaxed/simple; bh=ymav331vsVMgmkxdRNxjYnYOZx7+481dvb9L+9JpaQ4=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=lvW9tB9OaLPHv+OkggpwKElKKEU9RlNhJXZ3//AvgbaUF3Ui4sL5DF8anLe4Xxd3OnM4gP/UNeiytkPYZp1TFykddaQkc7qtkApSR/CvkZJxrURIjId8gnMKGfNejE1QqZUNB6BjPj1MtR8IHq0aL/KmWBfej4M3i6xCKi66RZM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from knuth.suse.de (unknown [IPv6:2a07:de40:a101:3:9249:faff:fe06:959]) by smtp-out1.suse.de (Postfix) with ESMTP id 025BD21A30; Tue, 4 Jun 2024 13:49:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1717508945; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xfNgLiD6GdHoMx8M2kBpa3FhHq7ImzXPuJqVCmXik6o=; b=M3xFxGzaWnrlMrYJvDY8LikTsm/PZpEaB74GZKWb9SU51RNnjvtFtDPEKR7kZx50iL8w+M sZIP/7be5obH+nVmWbzJXsXK/gDvmuZhwRedDKLEywUL3a2JXsFBjAVz/FLETcyRna6cTQ sBmTbYhzHW7SFQik55M8JdaNwibRmrY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1717508945; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xfNgLiD6GdHoMx8M2kBpa3FhHq7ImzXPuJqVCmXik6o=; b=BqQKDfQEeUCsBFbz17cPFeK9pO3Z7wS00giS5NnSNwpzrVt259s7JvcVs/4x/Hgy3P7936 fPKmAIdYEADHUYAA== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=WGxBbc98; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=QmSL2u2A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1717508944; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xfNgLiD6GdHoMx8M2kBpa3FhHq7ImzXPuJqVCmXik6o=; b=WGxBbc981v/dQ7NAvh9IkOFBWVxVI4pDnyvjUYNsIpX5ib7QXs8vfFWK89rdO5OahtWIAb 6Qb+9/sgHmMl9tJRj/+3wX55AdYeVfUJtIKDeCfpiPUaaUHxinglKtatgystyPuQ4A7xh3 8bQ0dKgVI4s7GYiQeGJLzPZnTVTN20k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1717508944; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xfNgLiD6GdHoMx8M2kBpa3FhHq7ImzXPuJqVCmXik6o=; b=QmSL2u2AfB/Iv2GW2vi2OBnYIi1rtOne6xD5t+SWXT+5Qi1rFasXqW0Qp997vJWMHwS+Kl Bmv2R8kYxs5cTLAw== Received: by knuth.suse.de (Postfix, from userid 10510) id DDCD6386F31; Tue, 4 Jun 2024 15:49:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by knuth.suse.de (Postfix) with ESMTP id CCE90386F30; Tue, 4 Jun 2024 15:49:03 +0200 (CEST) Date: Tue, 4 Jun 2024 15:49:03 +0200 (CEST) From: Michael Matz To: Jakub Jelinek cc: Andi Kleen , gcc-patches@gcc.gnu.org, Richard Biener Subject: Re: [PATCH v6 1/8] Improve must tail in RTL backend In-Reply-To: Message-ID: <48d91e0f-129b-5cea-2f9e-edad9a023f23@suse.de> References: <20240521143203.2893096-1-ak@linux.intel.com> <20240521143203.2893096-2-ak@linux.intel.com> <357aa546-91d8-8d98-f941-ac2bdafab656@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Level: X-Spamd-Result: default: False [-0.11 / 50.00]; BAYES_HAM(-3.00)[100.00%]; HFILTER_HOSTNAME_UNKNOWN(2.50)[]; DWL_DNSWL_MED(-2.00)[suse.de:dkim]; SUSPICIOUS_RECIPS(1.50)[]; RDNS_NONE(1.00)[]; HFILTER_HELO_IP_A(1.00)[knuth.suse.de]; NEURAL_HAM_LONG(-1.00)[-1.000]; HFILTER_HELO_NORES_A_OR_MX(0.30)[knuth.suse.de]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_NO_TLS_LAST(0.10)[]; MX_GOOD(-0.01)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; ARC_NA(0.00)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_TRACE(0.00)[suse.de:+]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[linux.intel.com,gcc.gnu.org,gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; MISSING_XM_UA(0.00)[]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim] X-Spam-Score: -0.11 X-Spamd-Bar: / X-Rspamd-Queue-Id: 025BD21A30 X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Rspamd-Action: no action X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, On Mon, 3 Jun 2024, Jakub Jelinek wrote: > > Hmm. I count six tests in about 25 lines of code in > > tree-tailcall.cc:suitable_for_tail_opt_p and suitable_for_tail_call_opt_p. > > > > Are you perhaps worrying about the sibcall discovery itself (i.e. much of > > find_tail_calls)? Why would that be needed for musttail? Is that > > attribute sometimes applied to calls that aren't in fact sibcall-able? > > > > One thing I'm worried about is the need for a new sibcall pass at O0 just > > for sibcall discovery. find_tail_calls isn't cheap, because it computes > > live local variables for the whole function, potentially being quadratic. > > But the pass could be done only if there is at least one musttail call > in a function (remembered in some cfun flag). If people use that > attribute, guess they are willing to pay for it. Yeah, but I think the way the current proposal is doing it is mostly equivalent and fine enough, as Andi mentioned (in my worry I haven't considered that overall the backward walk stops fairly soon and then only does something when a musttail is there). I still think that the tree pass being necessary for correctness is bad design, in the grand scheme of things, especially for those tests that are done for the call statement in isolation (i.e. tests about arguments like address-taken and suchlike, and return value, flags on the callee, and facts about the current function). Those should all move to calls.cc or cfgexpand IMHO. But I will yield on the discovery part that tree-tailcall is doing (i.e. those pieces that need to look at multiple statements, e.g. how the call result is used later); those are a bit harder to do in expand and how it's structured, and without getting rid of that part in tree-tailcall we have to run it at O0 anyway for musttail. And moving only parts of the tests to calls.cc doesn't seem so worthwhile to hold up the patch. So, I have no objections on the patch design anymore. Ciao, Michael.