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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#55831): https://edk2.groups.io/g/devel/message/55831 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] -=-=-=-=-=-=-=-=-=-=-=-
