> -----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.ch...@hpe.com>
> Cc: devel@edk2.groups.io; ler...@redhat.com; Schaefer, Daniel (DualStudy)
> <daniel.schae...@hpe.com>; Chen, Gilbert <gilbert.c...@hpe.com>;
> af...@apple.com; michael.d.kin...@intel.com; p...@akeo.ie; Ard
> Biesheuvel <ard.biesheu...@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:l...@nuviainc.com]
> > > Sent: Friday, March 13, 2020 5:20 AM
> > > To: devel@edk2.groups.io; ler...@redhat.com
> > > Cc: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>;
> > > Schaefer, Daniel (DualStudy) <daniel.schae...@hpe.com>; Chen,
> > > Gilbert <gilbert.c...@hpe.com>; af...@apple.com;
> > > michael.d.kin...@intel.com; p...@akeo.ie; Ard Biesheuvel
> > > <ard.biesheu...@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
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#55855): https://edk2.groups.io/g/devel/message/55855
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]
-=-=-=-=-=-=-=-=-=-=-=-
