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

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

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

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

> 
> We could. And have no time left for resolving any issues that may be
> triggered by that without slipping the next stable tag. I would prefer de-
> risking it.
> 
> > IIUC, the CreateDeviceManagerForm() code in question did break an edk2
> > rule ("don't use structure assignment") *prior* to commit 64a228f5f893.
> > The rule violation was in commit 32465d9ae7ee; RISC-V only exposed it.
> > This doesn't seem uncharted territory.
> 
> I don't understand, I've already said I'm not pushing to revert that patch, I
> have suggested that we don't put RISC-V on less stable ground than
> ARM/AARCH64.
> 
> But continuing on the unrelated topic:
> If the rule is "no structure assignments", then fine, that's part of the C dialect
> you need to learn in order to contribute to TianoCore.
> I can separately start arguing for changing that rule.
> However, I can't easily find that in the coding style - could you give me a
> pointer?
> 
> /
>     Leif