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 DAE16C433FE for ; Thu, 17 Nov 2022 11:48:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234921AbiKQLsX (ORCPT ); Thu, 17 Nov 2022 06:48:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233622AbiKQLsU (ORCPT ); Thu, 17 Nov 2022 06:48:20 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01F6659179 for ; Thu, 17 Nov 2022 03:48:19 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1668685697; 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=OQRVxv4eDJN1w5/JmXIKbLq1cQLNQYpFeLVVJODDHV4=; b=og2a+MD1g6dE80MLtdn0Iy7bvkmimzOmW6gGuLVNBJGUcnMNjoeO/NgpKBw8kKMSUL52dj lPgoRhPZyjHAOHHWbwk2GoIZuprGLMHaiCmyIdC2Scav2SYT8hlSZ5lIsgkmMtf58ANgVI 7jopDWcL0LONzmMrK5WAJX8FBcDxWPR6FDrGRPoA1nF0mDzhVpSIqxLDqUkqpfbienga7Y V5KTbcamtxRe65doq9mZgPBlmSlt6TrGL4JlkP9t3+xqnBe8AdDDRJ92JC1sFBR6A1O3P8 VyUBU+P20EEbKx+WXizKUEl4uXTXDxM6CAcIGub8AxfHfBq9jWmJN1CuRSGpfQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1668685697; 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=OQRVxv4eDJN1w5/JmXIKbLq1cQLNQYpFeLVVJODDHV4=; b=fFbYefAwWydI9Eoyrx/NoI9ndxShrxy+0QsiypTqReObRJ6SiOI4J14NnipkDct+WqWhAS 8KIMQVKuuTDKQUDw== To: Richard Biener , Peter Zijlstra Cc: Ard Biesheuvel , "Jiri Slaby (SUSE)" , linux-kernel@vger.kernel.org, Alexander Potapenko , Alexander Shishkin , Alexei Starovoitov , Alexey Makhalov , Andrew Morton , Andrey Konovalov , Andrey Ryabinin , Andrii Nakryiko , Andy Lutomirski , Arnaldo Carvalho de Melo , Ben Segall , Borislav Petkov , Daniel Borkmann , Daniel Bristot de Oliveira , Dave Hansen , Dietmar Eggemann , Dmitry Vyukov , Don Zickus , Hao Luo , "H . J . Lu" , "H. Peter Anvin" , Huang Rui , Ingo Molnar , Jan Hubicka , Jason Baron , Jiri Kosina , Jiri Olsa , Joe Lawrence , John Fastabend , Josh Poimboeuf , Juergen Gross , Juri Lelli , KP Singh , Mark Rutland , Martin KaFai Lau , Martin Liska , Masahiro Yamada , Mel Gorman , Miguel Ojeda , Michal Marek , Miroslav Benes , Namhyung Kim , Nick Desaulniers , Oleksandr Tyshchenko , Petr Mladek , "Rafael J. Wysocki" , Richard Biener , Sedat Dilek , Song Liu , Stanislav Fomichev , Stefano Stabellini , Steven Rostedt , Valentin Schneider , Vincent Guittot , Vincenzo Frascino , Viresh Kumar , VMware PV-Drivers Reviewers , Yonghong Song Subject: Re: [PATCH 00/46] gcc-LTO support for the kernel In-Reply-To: References: <20221114114344.18650-1-jirislaby@kernel.org> Date: Thu, 17 Nov 2022 12:48:17 +0100 Message-ID: <87iljdn6ny.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 08:50, Richard Biener wrote: > On Thu, 17 Nov 2022, Peter Zijlstra wrote: >> Seconded; I really hate all the ugly required for the GCC-LTO >> 'solution'. There not actually being any benefit just makes it a very >> simple decision to drop all these patches on the floor. > > I'd say that instead a prerequesite for the series would be to actually > enforce hidden visibility for everything not part of the kernel module > API so the compiler can throw away unused functions. Currently it has > to keep everything because with a shared object there might be external > references to everything exported from individual TUs. > > There was a size benefit mentioned for module-less monolithic kernels > as likely used in embedded setups, not sure if that's enough motivation > to properly annotate symbols with visibility - and as far as I understand > all these 'required' are actually such fixes. To accomodate a broken tool which cannot figure out which functions are referenced in the final lump and which are not, right? Can we pretty please fix the tool instead of proliferating the brokenness? Thanks, tglx