From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.9513.1687860895451860941 for ; Tue, 27 Jun 2023 03:14:55 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ubOegCbU; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BA217610A6 for ; Tue, 27 Jun 2023 10:14:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CA6AC433C8 for ; Tue, 27 Jun 2023 10:14:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687860894; bh=qH7GJ5dxa9mLteIGRGGmdoiYuH9FbayKN5r+0Ry3b8Y=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ubOegCbUy50DPeuSRSkHSK53FI5DFKacMzvvXXETwTjyG4qMVYMBk/VbEbXSvH6nB BXttONWHq+4U4MPwRcbYLQgGraKRMznv/pB0fiGO4izwjaHyYUrIerdnZagaV3UBV+ P7dAFB72P683wmtpoPUDk6dzv18cIoirCVoc0N/HXxWE9PuykG/MXrkl+NP3ySxjr8 8rNZjyvdrlGRkD3h4K1LQP7aaw6jRZLsX8ZnOW08bXt6kmbTxtIwtzER74n9xgjQtR TBayp5YDsAsOjPpG22yunNrEqHz19+LhqQ+3TQtYgSF+KYMCB6CEmeWCalf2yT8ZCM Meg+R34najH3A== Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-4fb7769f15aso2715587e87.0 for ; Tue, 27 Jun 2023 03:14:54 -0700 (PDT) X-Gm-Message-State: AC+VfDzWpkgadjMMzJnUm5SwetDrJL8AiH22WYvexuxdKGnBbeU/uGrt LRCeCFvZy5tTW5re0GpJxhTyolNdv40Q3N70slg= X-Google-Smtp-Source: ACHHUZ4+4zJFXUDrnfYoxG8fVCmMn3dWLdTi3j4rs8zYFQt/mpYs2o9mTSRARweKp4fsdl/9eYqbAz3f80UvG6h32Jo= X-Received: by 2002:a19:2d58:0:b0:4f8:5755:5b22 with SMTP id t24-20020a192d58000000b004f857555b22mr17476116lft.27.1687860892172; Tue, 27 Jun 2023 03:14:52 -0700 (PDT) MIME-Version: 1.0 References: <20230620111139.21365-1-yi1.li@intel.com> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 27 Jun 2023 12:14:40 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH] OvmfPkg/PlatformCI: Skip GCC5_OVMF_IA32X64_FULL_NOOPT build To: Pedro Falcato Cc: Gerd Hoffmann , edk2-devel-groups-io , yi1.li@intel.com, Ard Biesheuvel , Jiewen Yao , Jordan Justen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 21 Jun 2023 at 16:13, Pedro Falcato wrote= : > > On Wed, Jun 21, 2023 at 8:55=E2=80=AFAM Gerd Hoffmann = wrote: > > > > On Wed, Jun 21, 2023 at 01:40:06AM +0100, Pedro Falcato wrote: > > > On Tue, 20 Jun 2023, 12:11 Li, Yi, wrote: > > > > > > > The effect of LTO is limited with optimization turned off, and bloc= ked > > > > the upgrade of Openssl3.0. We already skipped this build with VS201= 9, > > > > skip the GCC NOOPT build also. > > > > > > > Hi, > > > > > > If LTO is the problem here, have you given ffunction-sections + > > > fdata-sections + gc-sections a spin? > > > > lto alone works and reduces size a bit, also turning on optimizations > > has a much bigger effect though. Which I suspect happens because gcc > > detects constant expressions then, calculates them at compile time > > instead of runtime, which in turn removes function calls in code paths > > never taken. > > Right, LTO is of course a lot less limited when it comes to this and > may give out further size reductions. But if we can't enable LTO (as > in NOOPT), gc-sections /may/ help here; gc-sections will *not* affect > debugging whatsoever. > Of course, whether this works is pure speculation; I personally > haven't tested this. > I don't mind this change, but could we also bump the FV size for NOOPT builds only? Or does that create problems elsewhere?