From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4654 invoked by alias); 25 Jan 2013 18:55:55 -0000 Received: (qmail 4645 invoked by uid 22791); 25 Jan 2013 18:55:54 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RP_MATCHES_RCVD,TW_CP X-Spam-Check-By: sourceware.org Received: from usmamail.tilera.com (HELO USMAMAIL.TILERA.COM) (12.216.194.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Jan 2013 18:55:11 +0000 Received: from [10.7.0.95] (10.9.0.23) by USMAExch2.tad.internal.tilera.com (10.3.0.33) with Microsoft SMTP Server id 14.0.694.0; Fri, 25 Jan 2013 13:55:09 -0500 Message-ID: <5102D50C.6030300@tilera.com> Date: Fri, 25 Jan 2013 18:55:00 -0000 From: Chris Metcalf User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Steve Ellcey CC: Subject: Re: [patch, mips, memmove] Remove memmove's use of memcpy on MIPS References: <8eea9547-6de4-482b-833c-f552df9283d4@EXCHHUB01.MIPS.com> In-Reply-To: <8eea9547-6de4-482b-833c-f552df9283d4@EXCHHUB01.MIPS.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2013-01/txt/msg00056.txt.bz2 On 1/25/2013 1:17 PM, Steve Ellcey wrote: > While doing some other testing Maciej Rozycki found a bug in the MIPS > memmove. A few weeks ago (after the release of 2.17) I updated the MIPS > memcpy.S to use the prepare-to-store prefetch instruction. This makes > memcpy (particularly long memcpy's) much faster. The problem is that the > prepare-to-store prefetch is not a 'real' prefetch, it doesn't read the > memory into the cache but, if the data is not already in cache, it creates a > cache line with all zeros and assumes that the user will write to the entire > line. If you try to read from that cache line or if you don't write to the > entire cache line before it is flushed you will get bad results. See ports/sysdeps/tile/tilegx/memcpy.c for how the tile architecture handles this issue. The memcpy code advances until the destination pointer is cache-aligned, then loops cacheline at a time, first reading 64 bytes, then doing the prepare-to-store (aka "wh64"), then writing all 64 bytes. This ensures that no matter what overlap the source has with the destination, we have captured any data that might be overwritten by the "wh64" instruction. Since our memory architecture is non-blocking we can issue all eight reads without waiting for them to complete. Would doing something like this for MIPS allow your memcpy to be safe for forward memmove? -- Chris Metcalf, Tilera Corp. http://www.tilera.com