Return-path: Received: from mx0.aculab.com ([213.249.233.131]:60866 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752873Ab2BFL1E convert rfc822-to-8bit (ORCPT ); Mon, 6 Feb 2012 06:27:04 -0500 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 26350-06 for ; Mon, 6 Feb 2012 11:27:01 +0000 (GMT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH 1/1] wireless: move ifs' in _rtl92c_store_pwrIndex_diffrate_offset into elseif statements Date: Mon, 6 Feb 2012 11:26:37 -0000 Message-ID: (sfid-20120206_122726_446926_9C555D05) In-Reply-To: <4F2EA8D8.4080907@lwfinger.net> From: "David Laight" To: "Larry Finger" , "Jan Ceuleers" Cc: "Devendra.Naga" , , , , , , , Sender: linux-wireless-owner@vger.kernel.org List-ID: > Yes, it is correct. It might be clearer if it were written as > a switch statement, but that would be a lot more intrusive. > Besides, have you ever looked at the way gcc compiles a switch? How gcc compiles a switch statement depends (amongst other things) on whether the labels form a 'dense set' or not. If they are dense it will usually generate a jump table. If they are not dense it will compare against the 'middle' entry first and generate a tree of conditionals. An 'else if' chain is a linear search. If the performance of the code matters in can be worth an explicit test for the common case outside the switch. Alternatively an 'if else' chain with every conditional marked 'unlikely' should generate exactly one mispredicted branch (if you can force static branch prediction). There are further constraints that apply to some cpus. Mostly it isn't worth worrying about - although a lot of code can be significantly sped up by avoiding/containing register spills and mis-predicted branches. The code is question seemed to be checking bits, not an ordinal - so changing to a case might be problematic. (Could more than one bit bet set????) David