From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16518 invoked by alias); 13 Aug 2010 07:28:12 -0000 Received: (qmail 16505 invoked by uid 22791); 13 Aug 2010 07:28:11 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_00,DKIM_ADSP_NXDOMAIN,NO_DNS_FOR_FROM X-Spam-Check-By: sourceware.org Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Aug 2010 07:28:06 +0000 Received: from gargoyle.firstfloor.org (p5B3C96B3.dip0.t-ipconnect.de [91.60.150.179]) by one.firstfloor.org (Postfix) with ESMTP id 15D4C1A9804F; Fri, 13 Aug 2010 09:28:04 +0200 (CEST) Date: Fri, 13 Aug 2010 08:33:00 -0000 From: Andi Kleen To: Richard Henderson Cc: Andi Kleen , gcc-patches@gcc.gnu.org Subject: Re: Vectorized _cpp_clean_line Message-ID: <20100813073002.GB12885@gargoyle.fritz.box> References: <4C601E08.4020303@google.com> <4C6035C2.9020505@moene.org> <4C60378B.4060303@google.com> <4C603AC2.5070403@moene.org> <45B5C4E0-DFA5-413E-8FC8-E13077862245@apple.com> <877hjy8qwk.fsf@basil.nowhere.org> <4C64699B.20804@redhat.com> <20100812220708.GC7058@basil.fritz.box> <4C647448.6080707@redhat.com> <4C647EC7.4010601@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C647EC7.4010601@redhat.com> User-Agent: Mutt/1.5.17 (2007-11-01) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00983.txt.bz2 On Thu, Aug 12, 2010 at 04:07:51PM -0700, Richard Henderson wrote: > On 08/12/2010 03:23 PM, Richard Henderson wrote: > > On 08/12/2010 03:07 PM, Andi Kleen wrote: > >> At least for sse 4.2 I'm not sure the table lookup > >> for alignment is worth it. The unaligned loads are quite > >> cheap on current micro architectures with sse 4.2 > >> and the page end test is also not that expensive. > > > > Perhaps. That's something else that will want testing, as > > it's all of a dozen instructions. > > Alternately, we can check for page end only at the end > of the buffer. Because obviously all the middle bits > of the buffer are present. Looks good. -Andi