From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) by dpdk.org (Postfix) with ESMTP id CD6CFA49F for ; Sat, 13 Jan 2018 23:05:15 +0100 (CET) Received: by mail-vk0-f51.google.com with SMTP id w75so5576551vkd.7 for ; Sat, 13 Jan 2018 14:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uuRUpri9QN58l5SpEKTjDmkZnoSyAfSoifjNA540/wk=; b=bnstXrcYk6oqIQp8IKjReVRuOpSluqOPLqevmPvsZPeenhY1DgFo+IN5NcrAwre9IG OJW5lHizgt3PxZasiEOzii3UUE3CqdU94Q/oBeLvnN0TDqSt5Qa9mNNuaT2ijyjaJoa6 23ZxQfZXAuNsvHd5kYsRoaQP6Tfmv8vU4Bb24ZnwvjB36EOt8kAAwzo1xUTdCpwfOR55 JOvsiHru6OQfX4EkTa6TLB5TjIzNdiAMTdGG5db1LZeDjWtJwtAkthtiFx3RDjA8WOnV TIWpczHwI1K32jliIQafDAM4v48loAmmaa/oEQFDeRcGUoBeM3QmdqwAHcG7b+Z4LztZ md/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uuRUpri9QN58l5SpEKTjDmkZnoSyAfSoifjNA540/wk=; b=GWeZkLVX6gf9aAM8j0W12VOkOX1y9yRSv5enaeboLeUUVINuBQbo2KQztTK/u6XCQc MShdFv6ArO8K394ffzvZXzD9hfMifQR8KcaHWQWZBU972UCtnfqdmH2x5XQmpI6O5Joj lpGvhGCtbOLSQ94kZNkXhE0Amn4qoSs5FS4nbI2S/87WtefCGi0pFjbjMocwLQO8lntH r/Xzu9bdKYa4ElWzyPkTHFU26iTCYlkhcxk8x885p+FjPmA4fCXYBSOPdzWwGvmAJag0 Zhy8eD8ll3trCHDIOb+CoomuzYueXO0HAS9ioz8SZ5QJAcRQpYBioLEgWXI9EJPVUOd5 x/jA== X-Gm-Message-State: AKGB3mJDCQY3vZqalgZpkjlBol7Ri1SdBTNPcLOiJGXZ4DZtjgaMc+RG 0+luJpXI1WEAzNLeMqyHKBaVdp2K45S6ftoDZV4r9g== X-Google-Smtp-Source: ACJfBotk/PoroL2EeTmcDhhVZjUAQr2DPv4Oz2B01Zm0tdWBJSW7HEoSyg91CCI/J/jLyHGeXRyojYXA/FNSIGZ9qPI= X-Received: by 10.31.6.83 with SMTP id 80mr26360992vkg.28.1515881115154; Sat, 13 Jan 2018 14:05:15 -0800 (PST) MIME-Version: 1.0 Sender: keshonok@gmail.com Received: by 10.31.166.148 with HTTP; Sat, 13 Jan 2018 14:05:14 -0800 (PST) In-Reply-To: <5180253.XvhpJrJZVt@xps> References: <1511129764-23123-1-git-send-email-Aleksey.Baulin@gmail.com> <5180253.XvhpJrJZVt@xps> From: Aleksey Baulin Date: Sun, 14 Jan 2018 01:05:14 +0300 X-Google-Sender-Auth: aD21HN9tyytMnbh6n9Z7_trePgo Message-ID: To: Thomas Monjalon Cc: dev@dpdk.org, "Wiles, Keith" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] eal/common: better likely() and unlikely() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 22:05:16 -0000 This is an interesting question. Perhaps, even a philosophical one. :-) 'likely(pointer)' is a perfectly legal statement in C language, as well as a concise one as compared to a more explicit (and redundant/superfluous) 'likely(pointer != NULL)'. If you _require_ this kind of explicitness in cases like this in the code style, then I have no argument here. However, I don't see that anywhere. There're other cases of explicitness, with the most widespread being a series of logical and compare operations in one statement. For instance, 'if (a > b && a < c)'. Explicitness would require writing it like this: 'if ((a > b) && (a < c))'. I've seen cases on this list where that was frowned upon as it's totally unnecessary due to C operator precedence rules, even though those statements, I think, looked better to their authors (actually, they do to me). Granted, it didn't lead to compiler errors, which is the case with the current implementation of 'likely()'. So, my answer to the question is yes, it's to avoid making pointer comparison explicit. I would add though, that it is to avoid making a perfectly legal C statement an illegal one, as with the way the current macro is constructed, compiler emits an error when DPDK is built. I write in C for many years with the most time spent in kernels, Linux and not, and I find it unnatural to always add a redundant '!= NULL' just to satisfy the current macro implementation. I would have to accept that though if it's a requirement clearly stated somewhere like a code style. As for an extra instruction, I believe that everything in DPDK distribution is compiled with optimization. So the execution speed in not a concern here. Perhaps there are cases where it's compiled without optimization, like debugging, but then I believe it's a non-issue. Hope my explanations shed some more light on this patch. :-) On Fri, Jan 12, 2018 at 6:35 PM, Thomas Monjalon wrote: > 21/11/2017 08:05, Aleksey Baulin: > > On Mon, Nov 20, 2017 at 4:36 PM, Wiles, Keith > wrote: > > > > On Nov 19, 2017, at 4:16 PM, Aleksey Baulin < > aleksey.baulin@gmail.com> > > > wrote: > > > > -#define unlikely(x) __builtin_expect((x),0) > > > > +#define unlikely(x) __builtin_expect(!!(x), 0) > > > > > > I have not looked at the generated code, but does this add some extra > > > instruction now to do the !!(x) ? > > > > Sorry for late response. Jim had given the correct answer already. > > You won't get an extra instruction with compiler optimization turned on. > > So this patch is adding an instruction in not optimized binary. > I don't understand the benefit. > Is it just to avoid to make pointer comparison explicit? > likely(pointer != NULL) looks better than likely(pointer). > -- Aleksey Baulin