From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36E51C4332F for ; Fri, 18 Nov 2022 01:28:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239980AbiKRB2M (ORCPT ); Thu, 17 Nov 2022 20:28:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235041AbiKRB2J (ORCPT ); Thu, 17 Nov 2022 20:28:09 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6F0116D4A7 for ; Thu, 17 Nov 2022 17:28:08 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1668734887; h=from:from:reply-to:subject:subject: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=E/uOAq27HWepm1hqB8gGgqIddmHBWCv9QGtuYTUirTs=; b=q0hJEFCUuVnEFgYt8eI169Sk/RNEe5RVFfu9GMLK45iva/WlxD2u31XMFTFhfNHPrNKoFJ oYrt5mSAPgBiPeK/pyafTN6JsOV7C7mJQqyMglCVI88oaIM8qbYp5FjqGkO/JJkksMWEsi NcuKMOoPWaqSBm39BhAUqM8iRjW++S+feBkY3KQSSFdw6W2EA08Hj1No2fRScn/ZtAS6bW 50gUVfp8F5LhqHiVWY2BhcJKgpnyTjaMGNulZ7mDxkjvL+vFpc2rzsQbzChZBe4YQvdwq4 zgvnAPe+U04MpMhxTJ3qJzJVEu8JAUy/jhFzDpSTmQGok64cE0Sm12qORkx6Pw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1668734887; h=from:from:reply-to:subject:subject: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=E/uOAq27HWepm1hqB8gGgqIddmHBWCv9QGtuYTUirTs=; b=Qj0CgMXy+F/yZi3h3s8cXHKYflU50c/Mi+oOS9LLwuXRXuoCWvpR8VFEePibs/ilnOxi/D rWxonOSABAHfEwDw== To: Andi Kleen , Peter Zijlstra Cc: "Jiri Slaby (SUSE)" , linux-kernel@vger.kernel.org, Andy Lutomirski , Martin Liska , Jiri Slaby Subject: Re: [PATCH 18/46] entry, lto: Mark raw_irqentry_exit_cond_resched() as __visible In-Reply-To: <289e03d2-be50-4249-343a-75dae302b0e5@linux.intel.com> References: <20221114114344.18650-1-jirislaby@kernel.org> <20221114114344.18650-19-jirislaby@kernel.org> <87a64qo4th.ffs@tglx> <289e03d2-be50-4249-343a-75dae302b0e5@linux.intel.com> Date: Fri, 18 Nov 2022 02:28:06 +0100 Message-ID: <8735ahkq55.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 17 2022 at 14:07, Andi Kleen wrote: >> Anyway; I think we can drop all this crazy on the floor again, since per >> the 0/n (which I didn't get) there isn't any actual benefit from using >> GCC-LTO, so why should we bother with all this ugly. > > At least in the past it generated smaller kernels for small configurations. > > One benefit that wasn't mentioned is doing type and other checks (e.g. > constant propagation > > through inlining) across files. > > In general LTO gives the compiler a lot more freedom to optimize code, > so even if it's not quite there > > yet I think it's beneficial to let users play around with it and see if > they can get benefits. Sure, they can play around with it but that does not require to merge all this nonsensical ballast for a half thought out compiler. If they want to do that they can apply the pile of patches as provided and play around. If anything useful comes out of that with sensible changelogs and a sensible argumentation why supporting a half thought out compiler is required then we can revisit that. Up to that point this is all considered to be __invisible. Thanks, tglx