From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27123 invoked by alias); 3 Apr 2013 15:48:05 -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 26987 invoked by uid 89); 3 Apr 2013 15:47:59 -0000 Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 03 Apr 2013 15:47:59 +0000 Received: from mail-wi0-f180.google.com ([209.85.212.180]) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1UNPun-0001xD-6m for libc-ports@sourceware.org; Wed, 03 Apr 2013 15:47:57 +0000 Received: by mail-wi0-f180.google.com with SMTP id c10so1675762wiw.13 for ; Wed, 03 Apr 2013 08:47:57 -0700 (PDT) X-Received: by 10.194.87.229 with SMTP id bb5mr3692263wjb.32.1365004077054; Wed, 03 Apr 2013 08:47:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.119.168 with HTTP; Wed, 3 Apr 2013 08:47:36 -0700 (PDT) In-Reply-To: References: From: "Shih-Yuan Lee (FourDollars)" Date: Wed, 03 Apr 2013 15:48:00 -0000 Message-ID: Subject: Re: [PATCH] ARM: NEON detected memcpy. To: "Joseph S. Myers" Cc: patches@eglibc.org, libc-ports@sourceware.org, rex.tsai@canonical.com, Jesse Sung , YC Cheng Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-04/txt/msg00010.txt.bz2 Hi Joseph, I know there is some legal homework but I don't know how to do it. Could you provide more details about how to put such copyright assignment (with some real example is better)? About raised power consumption and context switch costs, I may be able to add some option in configure for the users to decide if they want to use this feature or not. How do you think? Regards, $4 On Wed, Apr 3, 2013 at 11:08 PM, Joseph S. Myers wrote: > On Wed, 3 Apr 2013, Shih-Yuan Lee (FourDollars) wrote: > >> I am working on the NEON detected memcpy. >> This is based on what Siarhei Siamashka did at 2009 [1]. > > I still don't see any copyright assignment on file (whether individual > with an employer disclaimer, or corporate) that would cover that work. > Without one, we can't use it, and I advise anyone working on NEON memcpy > not to look at it. > > I was previously told by people at ARM that NEON memcpy wasn't a good idea > in practice because of raised power consumption, context switch costs etc. > from using NEON in processes that otherwise didn't use it, even if it > appeared superficially beneficial in benchmarks. > > -- > Joseph S. Myers > joseph@codesourcery.com