From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::22b; helo=mail-it0-x22b.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 65ED121B02820 for ; Thu, 7 Dec 2017 12:38:22 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id p139so148969itb.1 for ; Thu, 07 Dec 2017 12:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qlzct7dMxDk4MDYuaFtxNNq/LxvwclBrFv+lwf4qvdw=; b=L+dqxTy+lY4n8GNCXf0fArieYVMhrZthJ04sHRTt2oNUbiDVryD4klwDevshWyUs7p VmsvJDOuQV3QwoozdFm/7kLKvjC/6wevvChcyS6P6gAPYlNeViEo3pJjxgJvj4HOy628 tD/y+CDDdqisOGkqxYxC8PpX+ZFm3zvU+9lSM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qlzct7dMxDk4MDYuaFtxNNq/LxvwclBrFv+lwf4qvdw=; b=hsY9qBdTzy0Cff80t57EavGk09v9VD7jqNuR5j1PNhvOwFiI8J8Kep4X23T9j8qS0h X/ntaQ93SCM8+1j3vAppR+N1NCMcHFr+4DIPz8x1liIGNTCr6jfKawex5P4chKAEcWgF zNrhzpTCjCLi0gciOmIoRVPZisXsSStq2DXg7qNfEhSQVneBUNgim2N/Eo3nDle/7f0T 8x75KmhT6LDqh985q1Prf5HE+L1eo9yXM1kOv+xC4EmesqbhlHjj/mEC93M3ZLSXME/7 afPwZ1ydlJpm2ePoPcl0BT+K2I1TIRe9NHJVdLobntBdBJyJlrIcbM8oJtn0xsTW/xBC L7XQ== X-Gm-Message-State: AKGB3mLHdGLMyMT2BdhBopw2xmjtmL7/aN/FpEj1PTn2kjBoHU8JAujw O1RhsPvikVuwdguwxfnhqxCe5aZQ5P8PKOrIdQGU+g== X-Google-Smtp-Source: AGs4zMaOVNXBGrCpejVyOmB9K/ClA5TaVpjs4naWYeKNka7kTICXnBHtUt5HrXemm0SAtoZAXtNjnK/XQ0e0DU8eFJs= X-Received: by 10.107.180.18 with SMTP id d18mr4625777iof.52.1512679375057; Thu, 07 Dec 2017 12:42:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.16 with HTTP; Thu, 7 Dec 2017 12:42:54 -0800 (PST) In-Reply-To: References: <20171207151208.25648-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Thu, 7 Dec 2017 20:42:54 +0000 Message-ID: To: "Kinney, Michael D" Cc: Alexei Fedorov , "edk2-devel@lists.01.org" , Leif Lindholm , "Gao, Liming" Subject: Re: [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 20:38:22 -0000 Content-Type: text/plain; charset="UTF-8" On 7 December 2017 at 20:33, Kinney, Michael D wrote: >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] >> On Behalf Of Ard Biesheuvel >> Sent: Thursday, December 7, 2017 11:53 AM >> To: Kinney, Michael D >> Cc: Alexei Fedorov ; edk2- >> devel@lists.01.org; Leif Lindholm >> ; Gao, Liming >> >> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if >> conditions in ASSERT_[EFI|RETURN]_ERROR >> >> On 7 December 2017 at 19:49, Kinney, Michael D >> wrote: >> > Ard, >> > >> > I do not disagree with your logic. >> > >> > The current algorithm is based on data from a long >> > time ago using what are now very old tool chains. >> > >> >> With LTO? > > Yes. The LTCG feature for VS tool chains. > >> >> > I will do some experiments on the currently supported >> > toolchains to see if the optimization is the same >> either >> > way. >> > >> >> Thank you. >> >> > I think the change you are suggesting is to improve >> > performance for optimization disabled builds by >> removing >> > an extra call. Is that correct? >> > >> >> Well, for DEBUG builds, yes. But given that the function >> call cannot >> be optimized away (on non-LTO builds), it affects >> optimized builds as >> well. > > Do you mean compiler optimizations enabled, but linker > optimizations disabled. > Basically, yes. LTO has only been added recently for GCC5 on ARM/AARCH64, and we are currently adding support for CLANG38 as well. CLANG35 and RVCT do not support LTO. So non-LTO still needs to be supported as well, and in some debugging/tracing contexts, having lots of needless function calls is making our lives difficult. (Hence my additional comment regarding ASSERT (), although I suppose in some cases, calculating the result of the expression could be more costly than the actual function call)