[RFC v2] non-temporal memcpy

[Morten Brørup]

> From: Stanisław Kardach [mailto:kda at semihalf.com]
> Sent: Tuesday, 19 July 2022 20.51
> 
> On Tue, Jul 19, 2022 at 8:41 PM Morten Brørup
> <mb at smartsharesystems.com> wrote:
> >
> > > From: David Christensen [mailto:drc at linux.vnet.ibm.com]
> > > Assume that fallback to the standard temporal memcpy is an
> acceptable
> > > implementation when not supported by the architecture, yes?
> >
> > Yes, that is exactly what I envisioned.
> >
> > Furthermore, stores unaligned to a degree not supported by the
> architecture, will also use temporal mempcy - at least for the
> unaligned first and last part of the copy. The middle (aligned) part
> may use non-temporal copy.
> >
> To clarify, would you envision implementation in the arch-specific
> headers + generic fallback or a shared one (generic unaligned + call
> to aligned arch-specific)? First one seems more lean.

Good feedback, Stanisław.

I agree that the first one is preferable.

It is also better prepared for some future platform supporting unaligned non-temporal load/store, if that is ever going to appear. :-)

> RISC-V will definitely use generic implementation as non-temporal
> load/store hints are still not ratified.

Yeah... my brief research on the topic showed that it had been suggested on some RISC-V mailing list, so I suppose it will get in there one day.

Not all CPUs have the same advanced features; and with memcpy() as a trustworthy fallback, I didn't expect anyone to object to this RFC on the basis of lack of support. I am pleased that both you (RISC-V maintainer) and Dave (POWER maintainer) are share this opinion, although not supported by your platforms. Thank you, both!

> --
> Best Regards,
> Stanisław Kardach