From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61201 invoked by alias); 9 May 2019 02:01:06 -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 61175 invoked by uid 89); 9 May 2019 02:01:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.4 required=5.0 tests=AWL,BAYES_00,SPF_FAIL,UNPARSEABLE_RELAY autolearn=no version=3.3.1 spammy=world X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 May 2019 02:01:02 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOYMl-00083D-0q for gcc-patches@gcc.gnu.org; Wed, 08 May 2019 22:01:01 -0400 Received: from out4436.biz.mail.alibaba.com ([47.88.44.36]:62176) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hOYMk-00080N-MA for gcc-patches@gcc.gnu.org; Wed, 08 May 2019 22:00:58 -0400 X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04420;MF=junma@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0TRDJoS8_1557367246; Received: from MacBook-Pro-3.local(mailfrom:JunMa@linux.alibaba.com fp:SMTPD_---0TRDJoS8_1557367246) by smtp.aliyun-inc.com(127.0.0.1); Thu, 09 May 2019 10:00:47 +0800 Subject: Re: [PATCH][Tree-optimization/PR89772]fold memchr builtins for character not in constant nul-padded string To: Richard Biener , Bernd Edlinger Cc: Martin Sebor , gcc-patches References: <40b287af-4c87-f8d2-daeb-774861f430f9@linux.alibaba.com> <1b5445db-9f92-9cc5-8f81-5e4a16a60580@linux.alibaba.com> <94813471-e5be-8c99-47c4-8f6ab0ecb815@linux.alibaba.com> From: JunMa Message-ID: Date: Thu, 09 May 2019 02:01:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 47.88.44.36 X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00396.txt.bz2 在 2019/5/8 下午10:31, Richard Biener 写道: > On Tue, May 7, 2019 at 4:34 AM JunMa wrote: >> 在 2019/5/6 下午7:58, JunMa 写道: >>> 在 2019/5/6 下午6:02, Richard Biener 写道: >>>> On Thu, Mar 21, 2019 at 5:57 AM JunMa wrote: >>>>> Hi >>>>> For now, gcc can not fold code like: >>>>> >>>>> const char a[5] = "123" >>>>> __builtin_memchr (a, '7', sizeof a) >>>>> >>>>> It tries to avoid folding out of string length although length of a >>>>> is 5. >>>>> This is a bit conservative, it's safe to folding memchr/bcmp/memcmp >>>>> builtins when constant string stores in array with some trailing nuls. >>>>> >>>>> This patch folds these cases by exposing additional length of >>>>> trailing nuls in c_getstr(). >>>>> Bootstrapped/regtested on x86_64-linux, ok for trunk? >>>> It's probably better if gimple_fold_builtin_memchr uses string_constant >>>> directly instead? >>> We can use string_constant in gimple_fold_builtin_memchr, however it is a >>> bit complex to use it in memchr/memcmp constant folding. >>>> You are changing memcmp constant folding but only have a testcase >>>> for memchr. >>> I'll add later. >>>> If we decide to amend c_getstr I would rather make it return the >>>> total length instead of the number of trailing zeros. >>> I think return the total length is safe in other place as well. >>> I used the argument in patch since I do not want any impact on >>> other part at all. >>> >> Although it is safe to use total length, I found that function >> inline_expand_builtin_string_cmp() which used c_getstr() may emit >> redundant rtls for trailing null chars when total length is returned. >> >> Also it is trivial to handle constant string with trailing null chars. >> >> So this updated patch follow richard's suggestion: using string_constant >> directly. >> >> Bootstrapped/regtested on x86_64-linux, ok for trunk? > Doesn't this fold to NULL for the case where seaching for '0' and it > doesn't occur in the string constant but only the zero-padding? For C case like：   const char str[100] = “hello world”   const char ch = '\0';   ret = (char*)memchr(str, ch, strlen(str));   ret2 = (char*)memchr(str, ch, sizeof str); then ret is null,  ret2 is not > So you'd need to conditionalize on c being not zero (or handle > that case specially by actually finding the first zero in the padding)? Yes, the string length return from c_getstr() including the termination NULL most of the time(when string_length <= string_size). If ch is NULL and the string length >= 3rd argument of memchr, then we donot need to handle this. Thanks JunMa > I think there was work to have all string constants zero terminated > but I'm not sure if we can rely on that here. Bernd? > > Richard. > >> Regards >> JunMa >> >> gcc/ChangeLog >> >> 2019-05-07 Jun Ma >> >> PR Tree-optimization/89772 >> * gimple-fold.c (gimple_fold_builtin_memchr): consider trailing nuls in >> out-of-bound accesses checking. >> >> gcc/testsuite/ChangeLog >> >> 2019-05-07 Jun Ma >> >> PR Tree-optimization/89772 >> * gcc.dg/builtin-memchr-4.c: New test. >>> Thanks >>> JunMa >>>> Richard. >>>> >>>>> Regards >>>>> JunMa >>>>> >>>>> >>>>> gcc/ChangeLog >>>>> >>>>> 2019-03-21 Jun Ma >>>>> >>>>> PR Tree-optimization/89772 >>>>> * fold-const.c (c_getstr): Add new parameter to get length of >>>>> additional >>>>> trailing nuls after constant string. >>>>> * gimple-fold.c (gimple_fold_builtin_memchr): consider >>>>> trailing nuls in >>>>> out-of-bound accesses checking. >>>>> * fold-const-call.c (fold_const_call): Likewise. >>>>> >>>>> >>>>> gcc/testsuite/ChangeLog >>>>> >>>>> 2019-03-21 Jun Ma >>>>> >>>>> PR Tree-optimization/89772 >>>>> * gcc.dg/builtin-memchr-4.c: New test.