On 7 December 2017 at 20:33, Kinney, Michael D <[email protected]> wrote: >> -----Original Message----- >> From: edk2-devel [mailto:[email protected]] >> On Behalf Of Ard Biesheuvel >> Sent: Thursday, December 7, 2017 11:53 AM >> To: Kinney, Michael D <[email protected]> >> Cc: Alexei Fedorov <[email protected]>; edk2- >> [email protected]; Leif Lindholm >> <[email protected]>; Gao, Liming >> <[email protected]> >> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if >> conditions in ASSERT_[EFI|RETURN]_ERROR >> >> On 7 December 2017 at 19:49, Kinney, Michael D >> <[email protected]> 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) _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
