This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Variations of memset()
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Matthew Wilcox <willy at infradead dot org>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 4 Aug 2017 20:57:57 +0000
- Subject: Re: Variations of memset()
- Authentication-results: sourceware.org; auth=none
- References: <20170804171117.GA13948@bombadil.infradead.org>
On Fri, 4 Aug 2017, Matthew Wilcox wrote:
> void *memset16(uint16_t *s, uint16_t v, size_t count);
> void *memset32(uint32_t *s, uint32_t v, size_t count);
> void *memset64(uint64_t *s, uint64_t v, size_t count);
Is your assertion that there are useful optimizations for these that
result in code too large for it to make sense for the compiler to inline
it, so an out-of-line function call is appropriate instead? I'd expect
the compiler to vectorize memset-like loops where appropriate, inline,
without needing such functions. Or is the desire to use IFUNCs for such
functions so code can be optimized for the processor it is running on,
without needing to be compiled for each processor with different vector
instructions that should be used?
(As noted, wmemset already provides memset32 semantics for all glibc
configurations, subject to any ABI questions of sign/zero extension of the
second argument for some ABIs if wchar_t is signed and this affects how
the argument is passed compared to uint32_t.)
--
Joseph S. Myers
joseph@codesourcery.com