Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3891152pxf; Mon, 15 Mar 2021 23:44:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9iGccaCoaQ/XAsHELkuNCSpjPbsk1fm1FMhs8kiqp5xozwMUAVBKQu8R2YN3QyCKayT45 X-Received: by 2002:a17:906:b747:: with SMTP id fx7mr28563996ejb.474.1615877074824; Mon, 15 Mar 2021 23:44:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615877074; cv=none; d=google.com; s=arc-20160816; b=uckdAPL9XdouZaW6aowBtkXKo3l23Fn1/6XRL/bEs2rSjL8BLmFLl64cjcxFk7qY5V OHfk+Viknnn5f+Y5SwUaz4Gf9vkMMLcQL09reWqquHDbNhXail49tw09vCh+hdsv6WYp dXxqQv9lqQHhDY80oE7O4IWLPJwN33ALKny9OmCRFSZ/U259ls3kDT5H73UXOXTj5iXl 0TLJJxYO++XnYSogxFZBN8727zZqMuUJR37PWxREJjoVH0Znl9mBWtW1etSdSzcVX8Al B0b1cy3d8VmG+Ol0dFS1tISboaYBGHcW8JhW5p43oqjZcAIFREcubaQT8C7gWN8GiDU1 zPxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=FUQDu0cpcSG/qWTWkcrIqPHmiliSK+deAGfMhXetR9g=; b=lT5aYaqQr+xsSVwcArYxKxUqe5W27YvlFnP/NqwmphWs/caXHJJIB4PODFCQMzpumD DOSP32rxOdALwvjyNO8uKxudFHUPkfRKSo0pwXizbnfUQ+i3n7cPV3Ezplh+5aqpw8Zn Coh7CdJG3FlvclM7rEP89cTo/P5xfr/cSIg9sIra/evsWPmrYC+RMxYt5+qDtZ/lczv4 Ox5mf21N1gBqLl0xv7oUx5vaXe3INi/MedMnxc6SXMJHEzquPLuzRntSXtXZg4uWZM3S rElZXliluABn2hCvRAzdSHTxkM78mqUgqVYOX4HYY30iiWjxltmA0IZND0UbMNRBsQix 4MFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j27si13007751edy.231.2021.03.15.23.44.12; Mon, 15 Mar 2021 23:44:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231397AbhCOXxm (ORCPT + 99 others); Mon, 15 Mar 2021 19:53:42 -0400 Received: from gate.crashing.org ([63.228.1.57]:44877 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232029AbhCOXxO (ORCPT ); Mon, 15 Mar 2021 19:53:14 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 12FNlGwa003537; Mon, 15 Mar 2021 18:47:16 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 12FNlEh4003533; Mon, 15 Mar 2021 18:47:14 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 15 Mar 2021 18:47:14 -0500 From: Segher Boessenkool To: Rasmus Villemoes Cc: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] powerpc/vdso32: Add missing _restgpr_31_x to fix build failure Message-ID: <20210315234714.GC16691@gate.crashing.org> References: <20210312022940.GO29191@gate.crashing.org> <023afd0c-dc61-5891-5145-5bcdce8227be@prevas.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <023afd0c-dc61-5891-5145-5bcdce8227be@prevas.dk> User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 15, 2021 at 05:23:44PM +0100, Rasmus Villemoes wrote: > On 12/03/2021 03.29, Segher Boessenkool wrote: > > On Tue, Mar 09, 2021 at 06:19:30AM +0000, Christophe Leroy wrote: > >> With some defconfig including CONFIG_CC_OPTIMIZE_FOR_SIZE, > >> (for instance mvme5100_defconfig and ps3_defconfig), gcc 5 > >> generates a call to _restgpr_31_x. > > > >> I don't know if there is a way to tell GCC not to emit that call, because at the end we get more instructions than needed. > > > > The function is required by the ABI, you need to have it. > > > > You get *fewer* insns statically, and that is what -Os is about: reduce > > the size of the binaries. > > Is there any reason to not just always build the vdso with -O2? It's one > page/one VMA either way, and the vdso is about making certain system > calls cheaper, so if unconditional -O2 could save a few cycles compared > to -Os, why not? (And if, as it seems, there's only one user within the > DSO of _restgpr_31_x, yes, the overall size of the .text segment > probably increases slightly). You can use exactly the same reasoning for using -O2 instead of -Os anywhere else. -Os doesn't mean "smaller code, but only where that is reasonable". It means "smaller code". Segher