From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7885 invoked by alias); 5 Sep 2013 11:54:25 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 7876 invoked by uid 89); 5 Sep 2013 11:54:25 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Sep 2013 11:54:25 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VHY8h-0006EY-7O from joseph_myers@mentor.com ; Thu, 05 Sep 2013 04:54:19 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Sep 2013 04:54:19 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Thu, 5 Sep 2013 12:54:17 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VHY8e-0006St-5M; Thu, 05 Sep 2013 11:54:16 +0000 Date: Thu, 05 Sep 2013 11:54:00 -0000 From: "Joseph S. Myers" To: "Ryan S. Arnold" CC: Siddhesh Poyarekar , Carlos O'Donell , =?UTF-8?B?T25kxZllaiBCw61sa2E=?= , Will Newton , "libc-ports@sourceware.org" , Patch Tracking Subject: Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance. In-Reply-To: Message-ID: References: <5220D30B.9080306@redhat.com> <5220F1F0.80501@redhat.com> <52260BD0.6090805@redhat.com> <20130903173710.GA2028@domone.kolej.mff.cuni.cz> <522621E2.6020903@redhat.com> <20130903185721.GA3876@domone.kolej.mff.cuni.cz> <5226354D.8000006@redhat.com> <20130904073008.GA4306@spoyarek.pnq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-09/txt/msg00043.txt.bz2 On Wed, 4 Sep 2013, Ryan S. Arnold wrote: > Simply testing for alignment (not presuming aligned data) itself slows > down the processing of aligned-data, but that's an unavoidable > reality. I've chatted with some compiler folks about the possibility > of branching directly to aligned case labels in string routines if the > compiler is able to detect aligned data.. but was informed that this > suggestion might get me burned at the stake. See the ARM EABI __aeabi_mem* functions. At present the glibc versions just wrap or alias the generic ones, so don't take advantage of the extra alignment information (and the constraints on register clobbers also mean plain ARM memcpy gets used for them rather than the NEON version). And GCC doesn't detect alignment and generate calls to those functions (which would be a pessimization anyway without glibc implementing these functions more optimally). But the principle makes sense, subject to not pessimizing real use cases by expanding libc code size unduly (different entry points to functions may be better than duplicating large amounts of code for each alignment case). -- Joseph S. Myers joseph@codesourcery.com