Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5168385ybp; Mon, 14 Oct 2019 16:50:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqwUpLLvY0rtKomiO8OU/iYkn+aWXu0puVqEwxGgfdbRRswwAxLcs2Kp6Xye7lvszutROq8n X-Received: by 2002:a17:906:fcce:: with SMTP id qx14mr31833014ejb.186.1571097029357; Mon, 14 Oct 2019 16:50:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571097029; cv=none; d=google.com; s=arc-20160816; b=u73EuXKJ5R1D6A/U9YOAExoBB1DxRZPcArL2qVJXaMK2U+vGGXe7gKS5Qv8Tt1UGwi 7ZMiU26bmOXpaF90W9HeS7G6q0LCQ6pz8S4hXbyN69vB/DzHmbuME9EYB3Fxit2kS+Ak btYWr2/XrD0sp0jhy0a8tlZxkIZpjkBNR+5KzKBWWQk+wDblXhuK/DNQ0ITLTlTp6tzi LR53Z7wTTxA149CeB39x4LB3PmLnUbCWD5skn5W1D8MISBBgx3wrB1YgMJCpt3ovbCMI l9wzCMSWf/BeX3EcCNDCpDsN/pX9l2w9u6+GUXjeO1NpPHaukBGhdVqdO9zJfzUuxWUf Iqzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Lw+dlNSOW1blwyz7LrsxUFCPlh216aneJ2xW1iaJxcA=; b=Bin6viFYAFgKAOSPKmsP7jct7g6+9uY9zwKxBUqF3GMRrPLAaO63PcZiXJlAQXipfN 4smJw3Wdy/gRBUUsSOYThk47pYdoGeQj/haOXZ/g0IfHKghus1gb18gkwDVGl0s3mgxr aOsmOi/Kh8/I4EhrqSl6x7v65Z5z6Wgcib9zyen1Yb2TE8a/ntXiEbRCHNjzzMwrMuSn sj7lM3qReSgf681DtJARurR24/mUQCiUzcBlrOxbTQS3M/utdosFjyOed1mMaAunkGcF VbAH7FjS8PSBzVzCPUd/hH84YKePXmnchf21RRKK6G67SZfexDlEqiktRMJYuB3HDSyj qaOg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r16si11883952edo.307.2019.10.14.16.50.06; Mon, 14 Oct 2019 16:50:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388024AbfJNTMG (ORCPT + 99 others); Mon, 14 Oct 2019 15:12:06 -0400 Received: from gate.crashing.org ([63.228.1.57]:48079 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732490AbfJNTMG (ORCPT ); Mon, 14 Oct 2019 15:12:06 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x9EJBhSD000977; Mon, 14 Oct 2019 14:11:43 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x9EJBgBM000976; Mon, 14 Oct 2019 14:11:42 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 14 Oct 2019 14:11:41 -0500 From: Segher Boessenkool To: Nick Desaulniers Cc: Nathan Chancellor , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , clang-built-linux , linuxppc-dev , LKML Subject: Re: [PATCH v4 3/3] powerpc/prom_init: Use -ffreestanding to avoid a reference to bcmp Message-ID: <20191014191141.GK28442@gate.crashing.org> References: <20190911182049.77853-1-natechancellor@gmail.com> <20191014025101.18567-1-natechancellor@gmail.com> <20191014025101.18567-4-natechancellor@gmail.com> <20191014093501.GE28442@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 14, 2019 at 08:56:12AM -0700, Nick Desaulniers wrote: > On Mon, Oct 14, 2019 at 2:35 AM Segher Boessenkool > wrote: > > > > On Sun, Oct 13, 2019 at 07:51:01PM -0700, Nathan Chancellor wrote: > > > r374662 gives LLVM the ability to convert certain loops into a reference > > > to bcmp as an optimization; this breaks prom_init_check.sh: > > > > When/why does LLVM think this is okay? This function has been removed > > from POSIX over a decade ago (and before that it always was marked as > > legacy). > > Segher, do you have links for any of the above? If so, that would be > helpful to me. Sure! https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap03.html Older versions are harder to find online, unfortunately. But there is https://kernel.org/pub/linux/docs/man-pages/man-pages-posix/ in which man3p/bcmp.3p says: FUTURE DIRECTIONS This function may be withdrawn in a future version. Finally, the Linux man pages say (man bcmp): CONFORMING TO 4.3BSD. This function is deprecated (marked as LEGACY in POSIX.1-2001): use memcmp(3) in new programs. POSIX.1-2008 removes the specification of bcmp(). > I'm arguing against certain transforms that assume that > one library function is faster than another, when such claims are > based on measurements from one stdlib implementation. Wow. The difference between memcmp and bcmp is trivial (just the return value is different, and that costs hardly anything to add). And memcmp is guaranteed to exist since C89/C90 at least. > The rationale for why it was added was that memcmp takes a measurable > amount of time in Google's fleet, and most calls to memcmp don't care > about the position of the mismatch; bcmp is lower overhead (or at > least for our libc implementation, not sure about others). You just have to do the read of the last words you compare as big-endian, and then you can just subtract the two words, convert that to "int" (which is very inconvenient to do, but hardly expensive), and there you go. Or on x86 use the bswap insn, or something like it. Or, if you use GCC, it has __builtin_memcmp but also __builtin_memcmp_eq, and those are automatically used, too. Segher