From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8754 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: _STRING_ARCH_unaligned or equivalent definition Date: Sat, 24 Oct 2015 13:57:04 +0200 Message-ID: <20151024115704.GM10551@port70.net> References: <562B4D9B.5070100@draigBrady.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1445687850 4421 80.91.229.3 (24 Oct 2015 11:57:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Oct 2015 11:57:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8767-gllmg-musl=m.gmane.org@lists.openwall.com Sat Oct 24 13:57:25 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZpxRn-0003qy-Ex for gllmg-musl@m.gmane.org; Sat, 24 Oct 2015 13:57:19 +0200 Original-Received: (qmail 14026 invoked by uid 550); 24 Oct 2015 11:57:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14002 invoked from network); 24 Oct 2015 11:57:16 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <562B4D9B.5070100@draigBrady.com> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:8754 Archived-At: * P?draig Brady [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.