public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Leif Lindholm" <leif@nuviainc.com>
To: "Chang, Abner (HPS SW/FW Technologist)" <abner.chang@hpe.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"lersek@redhat.com" <lersek@redhat.com>,
	"Schaefer, Daniel (DualStudy)" <daniel.schaefer@hpe.com>,
	"Chen, Gilbert" <gilbert.chen@hpe.com>,
	"afish@apple.com" <afish@apple.com>,
	"michael.d.kinney@intel.com" <michael.d.kinney@intel.com>,
	"pete@akeo.ie" <pete@akeo.ie>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment
Date: Fri, 13 Mar 2020 10:10:45 +0000	[thread overview]
Message-ID: <20200313101045.GN23627@bivouac.eciton.net> (raw)
In-Reply-To: <TU4PR8401MB042941E911085E1A65236EF7FFFA0@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM>

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?

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

  reply	other threads:[~2020-03-13 10:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02 10:32 [PATCH v2 0/3] Allow building MdeModulePkg on non-x86 Daniel Schaefer
2020-03-02 10:32 ` [PATCH v2 1/3] MdeModulePkg: Restrict libraries using SMM to x86 Daniel Schaefer
2020-03-02 13:18   ` [edk2-devel] " Liming Gao
2020-03-02 17:38     ` Daniel Schaefer
2020-03-02 10:32 ` [PATCH v2 2/3] MdeModulePkg: Set PcdDxeIplSwitchToLongMode false on non-x86 Daniel Schaefer
2020-03-02 13:19   ` Liming Gao
2020-03-02 17:36     ` Daniel Schaefer
2020-03-02 10:32 ` [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment Daniel Schaefer
2020-03-02 13:38   ` [edk2-devel] " Liming Gao
2020-03-05  0:39   ` Dandan Bi
2020-03-12  5:58     ` [edk2-devel] " Wang, Jian J
2020-03-12  6:00       ` Abner Chang
2020-03-12 10:55   ` Leif Lindholm
2020-03-12 12:21     ` Ni, Ray
2020-03-12 13:53       ` [EXTERNAL] " Leif Lindholm
2020-03-20  7:24         ` Ni, Ray
2020-03-12 13:24     ` Daniel Schaefer
2020-03-12 14:03       ` Leif Lindholm
2020-03-12 14:33         ` Abner Chang
2020-03-12 14:44           ` Leif Lindholm
2020-03-12 14:57             ` Leif Lindholm
2020-03-13  3:57               ` Abner Chang
2020-03-12 19:42             ` Laszlo Ersek
2020-03-12 21:19               ` Leif Lindholm
2020-03-13  4:08                 ` Abner Chang
2020-03-13 10:10                   ` Leif Lindholm [this message]
2020-03-15 14:59                     ` Abner Chang
2020-03-13 16:36                 ` Laszlo Ersek
2020-03-12 19:36         ` Laszlo Ersek
2020-03-12 19:51           ` Andrew Fish
2020-03-12 21:04           ` Leif Lindholm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200313101045.GN23627@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox