Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

["Leif Lindholm" <leif@nuviainc.com>]

On Thu, Mar 12, 2020 at 20:36:04 +0100, Laszlo Ersek wrote:
> On 03/12/20 15:03, Leif Lindholm wrote:
> > +Ard, Laszlo.
> > 
> > I think it would make sense to move it to MdeModulePkg (or MdePkg) and
> > rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
> > 
> > As I alluded in my reply to Ray - x86 also have this problem, but to a
> > lesser extent, and ended up creating library functions to call instead
> > of using plain C for certain operations.
> > Which was probably the right decision when it was restricted to a
> > very few corner cases.
> 
> I think people that are interested in IA32/X64 are happier with explicit
> CopyMem() calls that are optimized (via one of the several BaseMemoryLib
> instances, such as SSE2, REP + string instructions, MMX, "smart"
> (chunked) C code, etc), than with a naive loop, such as the one in
> "ArmPkg/Library/CompilerIntrinsicsLib/memcpy.c", that gets silently
> plugged into an intrinsic (such as a structure assignment).
> 
> I mean, compiler intrinsics exist in the first place because they
> implement language features in a fast / performant manner, behind the
> scenes.

That may have been the original intent. The end result is we *have*
them, so we must do something about them.

> If we replace the internals of an intrinsic with a slow / naive
> implementation, then the intrinsic has no more right to exist, the
> compiler could / should just generate the normal naive code.

Sure. That's a toolchain issue, which we don't always control.

In the case of CopyGuid() I would take some convincing that there was
a significant difference in performance across 16 bytes of cached
memory, performed occasionally.

But, if there was, we could do

--- a/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
@@ -86,3 +86,4 @@ [Packages]
[BuildOptions]
   MSFT:*_*_*_CC_FLAGS = /GL-
   MSFT:*_*_ARM_ASM_FLAGS = /oldit
+  GCC:RELEASE_*_*_CC_FLAGS = -O3

and let idiom recognition take care of inserting the optimised
versions in place of the naive ones.

> I don't mind the code movement, but I'd like to avoid using
> BaseCompilerIntrinsicsLib on IA32/X64. On those arches, I think it would
> only be an improvement if it had a configurable backend, similarly how
> CopyMem() is currently configurable.

With less than making CompilerIntrinsicLib *not* a BASE library
(urgh), we can't have *it* depending on platform-specific optimised
versions.

The comment about IA32/X64 was more about the few instances we've seen
where new code has broken them due to things like dividing 64-bit
values withouy function calls, and how in the future it might make
sense catching that in other ways.

> ... I guess I've gotten very used to calling CopyMem(), in place of
> structure assignment.

Basically, I don't think having to learn a new dialect of C is
consistent with lowering the barrier of entry to the project.

Regards,

Leif