[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151024115704.GM10551@port70.net>
Date: Sat, 24 Oct 2015 13:57:04 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: _STRING_ARCH_unaligned or equivalent definition
* 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.
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.
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.
