From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23446 invoked by alias); 26 Oct 2016 18:09:43 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 23436 invoked by uid 89); 26 Oct 2016 18:09:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=sawdey, Sawdey, routing, arch-specific X-HELO: mail-ua0-f170.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=f3WgtyNFapibITpq9mgXLBZElzadTNmtVqLgE2pKBxg=; b=LIfjWLE+F2gYz69JDLav+d/rtFjLDkjw5uTPSnKTp3lc51preuXpv+sKLX5xZjWSxF NduGn9D8JNbyIaSnZSpiv3ITRhhlCFg8rwvNKNS3JR8l2VYgFAi5W48ldUtuzJu1LFvE eiheq8hImkEsS+zZs+XhTyxHXLd40AZr7cb0ZZuBIVYgEAhtsJVfcOGO442O7zBqn6dR gQkSJ1hRbSB2LDFVw5x8MovdSR440VCV0mGBSMjlTZVC2sjfjPqzZfEZR0Ev/yfiW6xl z+zTbtZofsvBI/L0rfLZDjAxl2rx84AhSxB6QG6lZNDP6/oZKwsRWejmGzSSIx24R9XR UACg== X-Gm-Message-State: ABUngvfbqKullK5ivTAnPD4vvYLDWr9htkBuPDBEmMD7eWwL7gbSFou8udStAVsRQAChGNAQ X-Received: by 10.176.85.85 with SMTP id u21mr2341202uaa.63.1477505370648; Wed, 26 Oct 2016 11:09:30 -0700 (PDT) Subject: Re: _HAVE_STRING_ARCH_strcpy/strncpy and ppc64 macro expansion of strcpy/strncpy. To: libc-alpha@sourceware.org References: <1477494262.5924.13.camel@linux.vnet.ibm.com> From: Adhemerval Zanella Message-ID: Date: Wed, 26 Oct 2016 18:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1477494262.5924.13.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-10/txt/msg00471.txt.bz2 On 26/10/2016 13:04, Aaron Sawdey wrote: > At present, powerpc uses the generic macros for strcpy/strncpy > expansion, which includes an expansion into code that compares the > strings character by character if one string is a string constant and > is less than 4 chars. > > I'm currently working on builtin expansion of strcmp/strncmp in gcc7 > for powerpc, similar to the memcmp builtin expansion I checked in a > couple weeks ago. This will potentialy generate much better code for > these short comparisons because gcc often knows the alignment which > allows it to generate word or doubleword comparisons reducing the > number of branches greatly. > > However as things currently stand, comparisons to constant strings < 4 > chars never see a strcmp/strncmp call because they get macro expanded > into comparison code. What would be helpful would be a change to have > powerpc specific code that doesn't invoke __strcmp_cg if compiled with > gcc7 or higher. > > Thanks, > Aaron > I think back when we lacked gcc support for string routing optimization the string{2,3}.h header optimization made sense, but currently it add more issue with multiple arch definition permutation and differences. For your specific issue I think it would be feasible to create a installed string.h with a arch-specific optimization (as for x86 and s390) with something like: #define _HAVE_STRING_ARCH_strcmp #ifndef _FORCE_INLINES __STRING_INLINE int strcmp (const char *__s1, const char *__s2) { return __builtin_strcmp (__s1, __s2); } #endif But I would rather prefer to evaluate if we *really* require the default and convoluted strcmp macro optimization. I think it would be just better to just remove it and let it the compiler handle it.