From owner-svn-src-head@freebsd.org Wed Sep 25 14:11:53 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3AD3E1284DB; Wed, 25 Sep 2019 14:11:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46dg3X1Xxhz3x1k; Wed, 25 Sep 2019 14:11:52 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f50.google.com with SMTP id b19so14213541iob.4; Wed, 25 Sep 2019 07:11:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YjVRbfd3bHIoWXaHMb7EUzhIPJwaEynUhBTN4KNXRW0=; b=psB6uDVv1OwVzzSL72cmPU8Z9xDx16r8BzeFb9tiX8ENsdcxQTa4sy9Jryppf+wQpl SIy/liPdwKf2V6q+hNnilZmPcLX9z1qDC1QxRERD1qxtyRsOfLzsKw/3zSnLEi/7+2PX +mJ4ONWj1D+VAkYUp50iS4gIjGVi7qLDfaDmQqFnCm9B22PeGHIpaQuQQDRWZ9OIAHwB LASYSHsrqRHMPIqx+b19rFAcF5xiE5G48ghFmqm5EQJnZnbqF9uNIRa78h+2pDs/S8FF gBxND93IG2gDAd+2zPqQG6aUn3r8tXYAOEMAVYR3xV8y+06GB7T1t5aegAh8TQQeswb7 0IYw== X-Gm-Message-State: APjAAAV0NJRp+sGG29ql5S8Tb0T1IFxwXWK/dpaprqTsLsRgOlSyjRc+ Gv0ej/6NdpqiofdgGj9LlYHwp3tWRlABTAAL7oZGUQ== X-Google-Smtp-Source: APXvYqwkc2jEyXOWTL70k0KXYjWAsBuTw0XEj/brXiD3d6EEA7duxHlYZoLteAOVIUu18NAm+w3L9oAfNb01tnPfnqo= X-Received: by 2002:a6b:3806:: with SMTP id f6mr10341684ioa.120.1569420711187; Wed, 25 Sep 2019 07:11:51 -0700 (PDT) MIME-Version: 1.0 References: <201909021356.x82Dui6v077765@repo.freebsd.org> <20190920212702.N1017@besplex.bde.org> In-Reply-To: <20190920212702.N1017@besplex.bde.org> From: Ed Maste Date: Wed, 25 Sep 2019 10:11:37 -0400 Message-ID: Subject: Re: svn commit: r351700 - head/lib/libc/string To: Bruce Evans Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 46dg3X1Xxhz3x1k X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[50.166.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.40)[ip: (-6.46), ipnet: 209.85.128.0/17(-3.30), asn: 15169(-2.18), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_TO(0.00)[optusnet.com.au]; RWL_MAILSPIKE_POSSIBLE(0.00)[50.166.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 14:11:53 -0000 On Fri, 20 Sep 2019 at 08:14, Bruce Evans wrote: > > Optimizing this function [memchr] is especially unimportant, Why? Really, we should provide optimized assembly implementations of string functions deemed important, but it will take time for that to happen on all architectures. > and this version has mounds of style bugs. Yes, I've wondered about applying style(9) to the handful of imported string routines. In general we don't really expect ongoing updates, so it's probably no concern from a maintenance perspective. > > - do { > > - if (*p++ == (unsigned char)c) > > - return ((void *)(p - 1)); > > - } while (--n != 0); > > Old KNF code. In the !__GNUC__ #else clause , this is replaced by > equivalent code with a style that is very far from KNF. Functionally equivalent, although I compared the compiled output of both cases and what's currently there is somewhat smaller. Note that it's not an #else case, the equivalent loop is used in both cases - handling the non-word-size residue in the __GNUC__ case. > > +void *memchr(const void *src, int c, size_t n) > > +{ > > + const unsigned char *s = src; > > + c = (unsigned char)c; > > +#ifdef __GNUC__ > > + for (; ((uintptr_t)s & ALIGN) && n && *s != c; s++, n--); > > + if (n && *s != c) { > > + typedef size_t __attribute__((__may_alias__)) word; > > This seems to have no dependencies on __GNUC__ except the use of anti-aliasing, Yes, that is the reason. > I checked that this optimization actually works. For long strings, it is > almost sizeof(size_t) times faster, by accessing memory with a size > sizeof(size_t). size_t is a not very good way of hard-coding the word size. Indeed - I wouldn't have imported this change if I didn't observe a reasonable benefit when trying it out. As for word size it could be replaced using LONG_BIT I suppose (as strspn.c, strlen.c), if it's getting reworked anyway. > Related silly optimizations: > - i386 has memchr() in asm. This uses scasb, which was last optimal on the > 8088, or perhaps the original i386. On freefall, it is several times slower > than the naive translation of the naive C code. I posted a review (https://reviews.freebsd.org/D21785) to remove the scasb implementation. I haven't investigated wmemchr. > - i386 pessimizes several old string functions using scasb. The only other one I see is in strcat.S, which should probably be retired as well. Are there others? > - i386 also does dubious alignment optimizations I don't think there's much value in putting a lot of time into i386, but am happy to address straightforward issues (such as removing pessimal MD implementations). I haven't looked at these alignment optimizations. > - amd64 pessimizes strcpy() by implementing it as a C wrapper for stpcpy(). > The wrapper code is MI, but is only used for amd64. And it appears the MD one is selected by Makefile .PATH ordering, which seems fragile.