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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
