https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
--- Comment #6 from Oleg Endo ---
(In reply to Rich Felker from comment #5)
> Of course, fancy memcpy in general is only a win beyond a certain size. For
> DMA I did not mean I want to use DMA for any size beyond gcc's proposed
> function-call th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
--- Comment #5 from Rich Felker ---
Of course, fancy memcpy in general is only a win beyond a certain size. For DMA
I did not mean I want to use DMA for any size beyond gcc's proposed
function-call threshold. Rather, the vdso-provided function wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
--- Comment #3 from Kazumoto Kojima ---
Created attachment 39642
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39642&action=edit
patch to add default threshold
256 sounds reasonable to me. Does the attached patch work for you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
--- Comment #2 from Rich Felker ---
Unless you expect the inline memcpy to be a size savings (and it does not seem
to be), the size threshold can just be chosen such that function call time is
negligible compared to copying time. I suspect that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
Kazumoto Kojima changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment
