Re: [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 7 December 2017 at 20:33, Kinney, Michael D
<michael.d.kinney@intel.com> 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 <michael.d.kinney@intel.com>
>> Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>; edk2-
>> devel@lists.01.org; Leif Lindholm
>> <leif.lindholm@linaro.org>; Gao, Liming
>> <liming.gao@intel.com>
>> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
>> conditions in ASSERT_[EFI|RETURN]_ERROR
>>
>> On 7 December 2017 at 19:49, Kinney, Michael D
>> <michael.d.kinney@intel.com> 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)