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

["Abner Chang" <abner.chang@hpe.com>]

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Leif Lindholm
> Sent: Friday, March 13, 2020 6:11 PM
> To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>
> Cc: devel@edk2.groups.io; lersek@redhat.com; Schaefer, Daniel (DualStudy)
> <daniel.schaefer@hpe.com>; Chen, Gilbert <gilbert.chen@hpe.com>;
> afish@apple.com; michael.d.kinney@intel.com; pete@akeo.ie; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> instead of GUID assignment
> 
> On Fri, Mar 13, 2020 at 04:08:12 +0000, Chang, Abner (HPS SW/FW
> Technologist) wrote:
> > > -----Original Message-----
> > > From: Leif Lindholm [mailto:leif@nuviainc.com]
> > > Sent: Friday, March 13, 2020 5:20 AM
> > > To: devel@edk2.groups.io; lersek@redhat.com
> > > Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>;
> > > Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com>; Chen,
> > > Gilbert <gilbert.chen@hpe.com>; afish@apple.com;
> > > michael.d.kinney@intel.com; pete@akeo.ie; Ard Biesheuvel
> > > <ard.biesheuvel@linaro.org>
> > > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use
> CopyMem
> > > instead of GUID assignment
> >
> > The current NULL instance of CompilerIntrinsicsLib is applied on every
> > modules, this means it's not flexible for overwriting memcpy (for
> > example) with the faster algorithm (such as SSEx instructions) for the
> > specific module in the same DSC, right? That says we can't assign a
> > special version of memcpy to just one particular module.
> 
> All true.
> But ... are you planning to contribute lots of code that performs large
> (certainly larger than GUIDs in order for effects to be
> noticeable) struct assignments on critical paths?
A huge block of memory copy or set indeed a requirement of HPE server BIOS for graphic mode BIOS setup without VGA H/W accelerator and others such as memory test, but it is x86 system though. . Respond to your feedback below, that should be fine if new code just use CopyMem for the high performance memory operations. RISC-V has no problem with using intrinsic memcpy, there is no strong performance requirements for memory operations so far...maybe later. 
> 
> Even if that is the case, as commented on the other fork of this
> thread: if we add the -O3 jiggle, GCC will automatically insert what it
> considers to be the optimal implementation for the specified target when
> encountering the naïve implementation.
> 
> > > On Thu, Mar 12, 2020 at 20:42:52 +0100, Laszlo Ersek wrote:
> > > > On 03/12/20 15:44, Leif Lindholm wrote:
> > > > > And what would you propose we do the next time the RISC-V
> > > > > toolchain generates a memcpy call based on some other completely
> > > > > valid change to core code?
> > > >
> > > > We could choose to enable the intrinsics library for RISC-V at that point.
> >
> > and I would like to see the flexibility of overwriting memory library
> > functions for particular modules. There is no special algorithm of
> > memory manipulation so far in RISC-V spec, however, the working group
> > of Vector extension does propose the new instruction sets.
> 
> Use of CompilerIntrinsicsLib has no effect on explicit CopyMem & co
> operations, only on memcpy/memset generated by the compiler. Which will
> generate build failures if not handled.
> 
> /
>     Leif
> 
>