From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6337 invoked by alias); 23 Sep 2016 14:11:18 -0000 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 Received: (qmail 6325 invoked by uid 89); 23 Sep 2016 14:11:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*M:online, Strlen, 1kb, 1KB X-HELO: mailout06.t-online.de Received: from mailout06.t-online.de (HELO mailout06.t-online.de) (194.25.134.19) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 23 Sep 2016 14:11:06 +0000 Received: from fwd01.aul.t-online.de (fwd01.aul.t-online.de [172.20.27.147]) by mailout06.t-online.de (Postfix) with SMTP id 8212C41C45C2; Fri, 23 Sep 2016 16:11:03 +0200 (CEST) Received: from [192.168.0.16] (GQiSC6ZDwhuhIuur9oK-hv9Dt91T5kZNj0EBF1OMeXAX8RU5OAKfZB6qgyJBmqAZ+k@[115.165.93.200]) by fwd01.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1bnRBs-16OmFU0; Fri, 23 Sep 2016 16:11:00 +0200 Message-ID: <1474639855.2578.2.camel@t-online.de> Subject: Re: [PATCH v3] Optimize strchr to strlen From: Oleg Endo To: Wilco Dijkstra , GCC Patches Cc: nd , Richard Biener , Jakub Jelinek Date: Fri, 23 Sep 2016 14:20:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01689.txt.bz2 On Fri, 2016-09-23 at 14:07 +0000, Wilco Dijkstra wrote: > After discussion (https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00718 > .html) > here is the latest version of the strchr patch.  This uses a gimple > statement for > the pointer addition so the gsi_prev always points at the strlen > call. > > Optimize strchr (s, 0) to s + strlen (s).  strchr (s, 0) appears a > common > idiom for finding the end of a string, however it is not a very > efficient > way of doing so.  Strlen is a much simpler operation which is > significantly > faster (eg. on x86 strlen is 50% faster for strings of 8 bytes and > about > twice as fast as strchr on strings of 1KB). > > OK for commit? Please add PR tree-optimization/61056 to the changelog so that it gets linked in bugzilla. Cheers, Oleg