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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24630C433DB for ; Wed, 10 Mar 2021 21:25:27 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9A8C264FA9 for ; Wed, 10 Mar 2021 21:25:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A8C264FA9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fluxnic.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RVxSC4URg1+7i/nEhk1Xd5ZccKSeESp9EnP1lgpxZQk=; b=TKtIWqYztZTfGOYlG0lLlRRRX Vo7Q6mSag/c/6ibMo2ff1259mjmYUj0QKHK6VOWI1EdzspTiip/KUzIfBhQIG+hbaYtyuyw11n8ji MTyF/40RW+kc4AGQk3Wa5/EWQa2ZDCTSj42fWW8Vsc72nqItRP0OHJTHaI4OB4+7YG06m54XatUmW N3fgU0GYu1hW8gMwhL7R5Z0ABEjZ1xzWLLjSr6HzIe2y3GeAXrsBZqDT8AaWNl2cMoK9SKQjnOEf7 vyBMvAI0zgg+i51W2Vw2yhzHllVPeSeZuCWEOqJmHkZ9ghAJhXMyLSlt7+az2nrcwYA8BGOSektc7 s+85oU9Cg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lK6IM-007mxD-GI; Wed, 10 Mar 2021 21:23:06 +0000 Received: from pb-sasl-trial2.pobox.com ([64.147.108.86]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lK6Ek-007lmu-Ms for linux-arm-kernel@lists.infradead.org; Wed, 10 Mar 2021 21:19:30 +0000 Received: from pb-sasl-trial2.pobox.com (localhost.local [127.0.0.1]) by pb-sasl-trial2.pobox.com (Postfix) with ESMTP id 3C0B2362D5; Wed, 10 Mar 2021 16:19:17 -0500 (EST) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=sasl; bh=+ikDOTaiocyRzcnsYX9MefRYaeU=; b=mBw3ZT HLb7f4zGl6oZKM9B1U2NSR2xaW/0m5e1NkBM+YdYpJNU151J5TFynTlMLFbbhQna rFPakgxHXn8FPp6kiuRcvYHGkv8SbHcTHZsa+eiuq/tnvh/DTJmPIhakbp29v8fU n2GgthUXshEMgvRgsdrNMCj3lTKg7fD/p3UMU= Received: from pb-smtp1.nyi.icgroup.com (pb-smtp1.pobox.com [10.90.30.53]) by pb-sasl-trial2.pobox.com (Postfix) with ESMTP id 1A606362D2; Wed, 10 Mar 2021 16:19:17 -0500 (EST) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type; s=2016-12.pbsmtp; bh=ze0IECsgkSchYV8g9uFehQ68VL1bMlDOcSVbtAt/QfI=; b=02i/XrhGxivkHajojkhNK3NV3e7xYD1CnAqLSQa++hhnJb33ixDuvOIK75UY3ExYvcOlwcDQlau9mSsK0aMhuBVcIqnhdbg6xJAvHnt+tnIxm7PahlCsq2aRkxUv2oD8wXTtPDqJDbyrUKgbEoTopU0AP8pkic/Pq64LUgauoiU= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 854AAB49BA; Wed, 10 Mar 2021 16:19:16 -0500 (EST) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 89D8C2DA004F; Wed, 10 Mar 2021 16:19:15 -0500 (EST) Date: Wed, 10 Mar 2021 16:19:15 -0500 (EST) From: Nicolas Pitre To: Nicholas Piggin cc: Arnd Bergmann , Fangrui Song , Ard Biesheuvel , Arnd Bergmann , Andrew Scull , Mark Brown , Catalin Marinas , clang-built-linux , David Brazdil , Geert Uytterhoeven , Ionela Voinescu , Kees Cook , Kristina Martsenko , Linux ARM , "linux-kernel@vger.kernel.org" , Mark Rutland , Marc Zyngier , Nathan Chancellor , Nick Desaulniers , Vincenzo Frascino , Will Deacon Subject: Re: [PATCH] [RFC] arm64: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION In-Reply-To: <1614559739.p25z5x88wl.astroid@bobo.none> Message-ID: <3o63p7pp-50o9-2789-s3qo-99pp5nrnnoqp@syhkavp.arg> References: <20210225112122.2198845-1-arnd@kernel.org> <20210226211323.arkvjnr4hifxapqu@google.com> <1614559739.p25z5x88wl.astroid@bobo.none> MIME-Version: 1.0 X-Pobox-Relay-ID: 450A1582-81E6-11EB-8521-D152C8D8090B-78420484!pb-smtp1.pobox.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210310_211923_591565_BD8A274F X-CRM114-Status: GOOD ( 24.99 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 1 Mar 2021, Nicholas Piggin wrote: > Excerpts from Arnd Bergmann's message of February 27, 2021 7:49 pm: > > Unlike what Nick expected in his submission, I now think the annotations > > will be needed for LTO just like they are for --gc-sections. > > Yeah I wasn't sure exactly what LTO looks like or how it would work. > I thought perhaps LTO might be able to find dead code with circular / > back references, we could put references from the code back to these > tables or something so they would be kept without KEEP. I don't know, I > was handwaving! > > I managed to get powerpc (and IIRC x86?) working with gc sections with > those KEEP annotations, but effectiveness of course is far worse than > what Nicolas was able to achieve with all his techniques and tricks. > > But yes unless there is some other mechanism to handle these tables, > then KEEP probably has to stay. I suggest this wants a very explicit and > systematic way to handle it (maybe with some toolchain support) rather > than trying to just remove things case by case and see what breaks. > > I don't know if Nicolas is still been working on his shrinking patches > recenty but he probably knows more than anyone about this stuff. Looks like not much has changed since last time I played with this stuff. There is a way to omit the KEEP() on tables, but something must create a dependency from the code being pointed to by those tables to the table entries themselves. I did write my findings in the following article (just skip over the introductory blurb): https://lwn.net/Articles/741494/ Once that dependency is there, then the KEEP() may go and garbage-collecting a function will also garbage-collect the table entry automatically. OTOH this trickery is not needed with LTO as garbage collection happens at the source code optimization level. The KEEP() may remain in that case as unneeded table entries will simply not be created in the first place. Nicolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel