From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id E39C33858D32 for ; Mon, 3 Jul 2023 18:54:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E39C33858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x236.google.com with SMTP id 5614622812f47-39ed11d6a50so3280615b6e.2 for ; Mon, 03 Jul 2023 11:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1688410473; x=1691002473; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=79kIGUFxBzKIa4LJHnH22rTCQATAFNLp+/UH/eT1ziQ=; b=KzCDUc36bCIThmw4Iux0t2b+AfNwWP8dXr9VtuRZtb2O9919AJgCDO3vRbmpTciv+v GqOiqK6SKI3SEOtyEkxz+X+5nnY9+BTxsxJaIxUAz2smyxApqcW5tAcluqf2c34uX0mc XMRZSaq9+bEr2VwzKj3aftucnm6iSnpM5j55Mb2fSXQCtc3MhSA6AzxnR/mxfA9O51RI qtcuguyB4za03Wsq2HF5lsOfXvlvgmpkwRIaDhHPoI4DzdhbsfoojPho0H3nS+xA5THS WCoWHNZq7Ntn+he2oVVa3ks9F9gAcmq5LntMa7lMbFuRKGFT54s11gwAOyBx+nzavfUn L5qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688410473; x=1691002473; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=79kIGUFxBzKIa4LJHnH22rTCQATAFNLp+/UH/eT1ziQ=; b=B1+mSelxPWJPkaa3gYsDDZmMEmaINUSzFDU9yhRSEMDQMVvg0QjcRsxMo6Ck18S3GE aWhCpAyRINhFOGGA3XO/1V/peyPcSZ9nweQn9aaGvxpCqLnxsbd5B3IKPXHw4pctjYVV DUuFofUDhIa9Zww52X+Lv/smV15ESLdpNLkqCSaqgSugNRNWxp96JcTa7QrlwuaqdyJI xdBwISZwKSChvyK7uLDslIyb/vwVDjcKVQI02WloHSB71kUk61R8HeDQMLhZOaQhA9M8 8U79260I8L7TMDgw43b0ZR2Dd6/VuXZGzQKRxY7igOi5DYJxYvDHGp7ZtSZbyJpOUovK NMVg== X-Gm-Message-State: AC+VfDw0jjA/znlfHTPeTBU0Sv3IU+wITAQxcwPJCA+QioBldVnc+40r r0bBqRWF3IrKgQ2Gfxw57t8ngPz2/ZGxcN1zmS9HRA== X-Google-Smtp-Source: ACHHUZ6rShG/HEgbIdVM52+rDqZEHI5yJUasEFfwyDwtI+P/9WACkoFX8kTYsJYEzYLPP31iFKLkEA== X-Received: by 2002:a05:6808:158a:b0:3a1:dc0d:f32b with SMTP id t10-20020a056808158a00b003a1dc0df32bmr10650375oiw.40.1688410472931; Mon, 03 Jul 2023 11:54:32 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:665c:4c86:ac7d:d2ce:ef? ([2804:1b3:a7c3:665c:4c86:ac7d:d2ce:ef]) by smtp.gmail.com with ESMTPSA id a9-20020a544e09000000b0039aa460e304sm10243985oiy.17.2023.07.03.11.54.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Jul 2023 11:54:32 -0700 (PDT) Message-ID: Date: Mon, 3 Jul 2023 15:54:29 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] x86_64: Implement AVX2 version of strlcpy/wcslcpy function Content-Language: en-US To: libc-alpha@sourceware.org References: <20230630204812.2059831-1-skpgkp2@gmail.com> <78aabdcb-bae8-abed-4ad1-ff9cc0285eab@cs.ucla.edu> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 03/07/23 15:40, Noah Goldstein via Libc-alpha wrote: > On Mon, Jul 3, 2023 at 11:30 AM Paul Eggert wrote: >> >> On 2023-06-30 15:21, Sunil Pandey wrote: >>> Attached is strcpy/wcslcpy microbenchmark data based on Noah >>> strlcpy/wcslcpy microbenchmark patch. >> >> Although it's helpful to know that the proposed patch improves >> microbenchmark scores, that's not enough to justify it. Let's see >> benchmarks of real programs. If they don't show significant wins, let's >> not bother. >> >> Programs that use strlcpy, by and large, don't use it in >> performance-sensitive areas, and their developers and users are far more >> worried about security than about performance. Making the implementation >> harder to audit will likely be a net negative for these applications. >> This doesn't sound a like a win at all. >> >> Plus, who uses wcslcpy? Why bother to tune it if nobody uses it? > > Think we should look into dropping optimized strcpy/wcscpy family > in general? For the most part don't see them in perf sensitive areas > anyways (generally people that care about perf maintain the length > and use mem* functions). I will go for it, these interface are provided mainly to comply with standards and for x86 it adds only more maintenance.