_STRING_ARCH_unaligned or equivalent definition

_STRING_ARCH_unaligned or equivalent definition

[Pádraig Brady]

Hi,

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?

thanks,
Pádraig.

Re: _STRING_ARCH_unaligned or equivalent definition

[Szabolcs Nagy]

* P?draig Brady <P@draigBrady.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.

this violates pointer aliasing rules and only the
compiler can give you guaranteed semantics (with
language extensions like attribute mayalias).

i don't think gcc has a predefined macro about
unaligned access (it is non-trivial to provide it
in a useful way because a platform may allow it,
but at a significant performance cost).

i think _STRING_ARCH_unaligned in glibc was not
supposed to be public api, it is used internally
to provide more efficient implementations (some
functions are implemented in the string header hence
it is publicly visible.. but don't assume such
variables will remain there after a glibc update).

when you do such low-level optimizations i think
you have to manually maintain the list of targets
the optimization is known to be valid for.

Re: _STRING_ARCH_unaligned or equivalent definition

[Rich Felker]

On Sat, Oct 24, 2015 at 01:57:04PM +0200, Szabolcs Nagy wrote:
> * P?draig Brady <P@draigBrady.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