[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20151024194348.GT8645@brightrain.aerifal.cx>
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.
