From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30677 invoked by alias); 18 Apr 2013 08:01:37 -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 30664 invoked by uid 89); 18 Apr 2013 08:01:37 -0000 X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_CP,TW_HW autolearn=ham version=3.3.1 Received: from mail-ie0-f181.google.com (HELO mail-ie0-f181.google.com) (209.85.223.181) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 18 Apr 2013 08:01:36 +0000 Received: by mail-ie0-f181.google.com with SMTP id tp5so538186ieb.12 for ; Thu, 18 Apr 2013 01:01:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ntWyEEn1VdhZYpR0t8ENfJHd9Lx4iQaLEXucetiRATM=; b=AY+WfZul2tbj3tycccxVkp9T8L8pdJXJt1xO7R8Et+/1choNENyY2YHJRUJ1i4668j LNSeNi/07VMDd3HNW6w2v6ThDXbvciQiA00nYATkM77LTDw4FWpXxUVZ3aAD7PDnqp77 OgGBl8d9+Rb16YwJSfZPLJociYBe8wtJHRiacTR/IM984n511uBLjMpwFbX6NsC4O19/ jyMuC6LNnreBei+TSpXv2Xa/MkQgJlTyGVXfLccueQrmI2X7/msOorVhsRTTamvHj+1K /31rDw5U3YKdnJWpM9Hu01zNdLqDXaRslpTZNDlSeBNaxFfKwiKJrTNWDzta4sADH6WG HzPw== MIME-Version: 1.0 X-Received: by 10.50.93.71 with SMTP id cs7mr6339824igb.53.1366272095178; Thu, 18 Apr 2013 01:01:35 -0700 (PDT) Received: by 10.64.100.174 with HTTP; Thu, 18 Apr 2013 01:01:34 -0700 (PDT) In-Reply-To: <516EE108.2030501@redhat.com> References: <516D18F0.4060009@linaro.org> <516EE108.2030501@redhat.com> Date: Thu, 18 Apr 2013 08:01:00 -0000 Message-ID: Subject: Re: [PATCH v2] ARM: Add Cortex-A15 optimized NEON and VFP memcpy routines, with IFUNC. From: Will Newton To: "Carlos O'Donell" Cc: libc-ports@sourceware.org, Patch Tracking Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmEsx4TyOe7t7Q/nTRJG9VQI8WBmIfU7Eq6ljzsR8jf0Gvh5iS8Y5/DF5U/0mr317WVLp4y X-SW-Source: 2013-04/txt/msg00087.txt.bz2 On 17 April 2013 18:51, Carlos O'Donell wrote: > On 04/16/2013 02:25 AM, Will Newton wrote: >> +size_t >> +__libc_ifunc_impl_list (const char *name, struct libc_ifunc_impl *array, >> + size_t max) >> +{ >> + size_t i = 0; >> + int hwcap; >> + >> + hwcap = GLRO(dl_hwcap); >> + >> + IFUNC_IMPL (i, name, memcpy, >> + IFUNC_IMPL_ADD (array, i, memcpy, hwcap & HWCAP_ARM_NEON, >> + __memcpy_neon) >> + IFUNC_IMPL_ADD (array, i, memcpy, hwcap & HWCAP_ARM_VFPv3, >> + __memcpy_vfp) >> + IFUNC_IMPL_ADD (array, i, memcpy, 1, __memcpy_arm)); >> + >> + return i; >> +} > > If unaligned access is a requirement why not check for it here? > > While unaligned access is virtually free on ARMv6 or higher it > is still possible for the U-bit to be disabled and for this to > crash on such systems. Does glibc support building for this type of system? The compiler will emit unaligned accesses by default on armv6 and above. Also there isn't a HWCAP bit for unaligned as far as I can tell. -- Will Newton Toolchain Working Group, Linaro