Date: Sat, 24 Oct 2015 15:43:48 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: _STRING_ARCH_unaligned or equivalent definition On Sat, Oct 24, 2015 at 01:57:04PM +0200, Szabolcs Nagy wrote: > * P?draig Brady <P@...igBrady.com> [2015-10-24 10:21:31 +0100]: > > I was writing some code which uses faster word at a time > > but possibly unaligned access when we know that unaligned > > access is OK, i.e. #if _STRING_ARCH_unaligned provided by glibc. > > > > I would like not to fall back to the slower path on musl. > > Is there a similar define for musl. Is is worth proposing > > a standard define somewhere? > > > > you have to negotiate with the compiler about this, > not with the libc. Indeed. Just because i386 allows misaligned accesses at the hardware level doesn't mean it's safe to write them in C code. A compiler is perfectly justified in assuming that, if _Alignof(int) is 4, reaching a statement that evaluates or assigns to *p (where p has type int*) implies that the low 2 bits of p are 0. It could use this knowledge to reduce the number of special cases needed for vectorization, or to optimize out a conditional like if ((uintptr_t)p % 4). I would actually not be surprised if firm's constbits analysis is capable of doing the latter. GCC may agree not to do these things for compatibility with legacy code, but that's compiler-specific and not something libc can promise. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.