> From: Stanisław Kardach [mailto:k...@semihalf.com] > Sent: Tuesday, 19 July 2022 20.51 > > On Tue, Jul 19, 2022 at 8:41 PM Morten Brørup > <m...@smartsharesystems.com> wrote: > > > > > From: David Christensen [mailto:d...@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
