From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 168E839960C6 for ; Wed, 9 Jun 2021 16:09:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 168E839960C6 Received: by mail-pl1-x62c.google.com with SMTP id x19so5646156pln.2 for ; Wed, 09 Jun 2021 09:09:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FVoXgu768V+JQRoez57svSC+sHQFbTtiZNghAxFd4Ig=; b=T8qR2wQtt057IVSyRPCVSuIrQI+YyD2jdWNL5UC0/ATw76GYf6RfR//enOU/K5JAF4 HCqNG4f1JCkX3vH5NZEVCIT+bn/vwB/H5jst0XYAWLeEauCbwiv24iEtDVM1ygIO1yne OraPRTwaZmEafs/+Gprut5c5u+FtjumvplxTJJZX6/tw7LMJZv1e3kITNcZfafP6cLy2 2G0R06/LPtVbdPsFsjVmzsD+ssQ5aIi1iUzKNMBECpX1JnZlwgvveTljAEtEnVGjVpHU 5LU9BH/0PoPz5oxjgViEwcGpxiA0cNg7dShVO2rudTcNDilg33iGQPNFXA/LxFXueHu1 E05g== X-Gm-Message-State: AOAM531SjdiNf3tVTKFUXAmcGtCoSaec+AhiBO91kuDJVAqo393nZOND pWMkHuUiaQviNi5ffwN1b18mS62Hyj5JUw== X-Google-Smtp-Source: ABdhPJwZOF03C71U89y+rnFsbpGXrfr9c5OmiX1MKdHPQZo7OeELzBBBuc4ATfiqn/JffU0TquDcXg== X-Received: by 2002:a17:902:728d:b029:113:23:c65f with SMTP id d13-20020a170902728db02901130023c65fmr470659pll.23.1623254974700; Wed, 09 Jun 2021 09:09:34 -0700 (PDT) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id n37sm92726pfv.47.2021.06.09.09.09.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Jun 2021 09:09:34 -0700 (PDT) Subject: Re: [PATCH] libgcc libiberty: optimize and modernize standard string and memory functions To: "Seija K." , "gcc-patches@gcc.gnu.org" References: From: Jeff Law Message-ID: <6883e021-1e45-585a-fcdd-e337835a1ff3@gmail.com> Date: Wed, 9 Jun 2021 10:09:31 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2021 16:09:37 -0000 On 6/3/2021 12:51 PM, Seija K. via Gcc-patches wrote: > This patch optimizes and simplifies many of the standard string functions. > > Since C99, some of the standard string functions have been changed to use > the restrict modifier. > > diff --git a/libgcc/memcmp.c b/libgcc/memcmp.c > index 2348afe1d27f7..74195cf6baf13 100644 > --- a/libgcc/memcmp.c > +++ b/libgcc/memcmp.c > @@ -7,10 +7,11 @@ memcmp (const void *str1, const void *str2, size_t count) > const unsigned char *s1 = str1; > const unsigned char *s2 = str2; > > - while (count-- > 0) > + while (count--) > { > - if (*s1++ != *s2++) > - return s1[-1] < s2[-1] ? -1 : 1; > + if (*s1 != *s2) > + return *s1 < *s2 ? -1 : 1; > + s1++, s2++; > } > return 0; > } I don't see the point behind this change and the similar ones in other files.  I'd like to see some justification for the change beyond just "this looks cleaner to me". > diff --git a/libgcc/memcpy.c b/libgcc/memcpy.c > index 58b1e405627aa..616df78fd2969 100644 > --- a/libgcc/memcpy.c > +++ b/libgcc/memcpy.c > @@ -2,7 +2,7 @@ > #include > > void * > -memcpy (void *dest, const void *src, size_t len) > +memcpy (void * restrict dest, const void * restrict src, size_t len) I would expect prototype fixes like this within libgcc to be reasonably safe. > diff --git a/libiberty/memcpy.c b/libiberty/memcpy.c > index 7f67d0bd1f26c..d388ae7f3506b 100644 > --- a/libiberty/memcpy.c > +++ b/libiberty/memcpy.c > @@ -19,7 +19,7 @@ Copies @var{length} bytes from memory region > @var{in} to region > void bcopy (const void*, void*, size_t); > > PTR > -memcpy (PTR out, const PTR in, size_t length) > +memcpy (PTR restrict out, const PTR restrict in, size_t length) It's not entirely clear that using "restrict" is safe because libiberty is used by so many other projects which may be building with old compilers, non-gcc compilers, etc. Generally the way to handle this is to use an autoconf check to confirm that the tools can handle the feature you want to use and ensure there's a fallback when they can't. Jeff