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

Laszlo Ersek lersek at redhat.com
Thu Mar 12 19:36:04 UTC 2020


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. 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.

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.

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

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55828): https://edk2.groups.io/g/devel/message/55828
Mute This Topic: https://groups.io/mt/71671270/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-





More information about the edk2-devel-archive mailing list