[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CBBC7E7@AcuExch.aculab.com>
Date: Tue, 20 Oct 2015 15:47:53 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Stephen Hemminger' <stephen@...workplumber.org>,
Michael Chan <mchan@...adcom.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"prashant@...adcom.com" <prashant@...adcom.com>,
"eddie.wai@...adcom.com" <eddie.wai@...adcom.com>,
"huangjw@...adcom.com" <huangjw@...adcom.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next v3] bnxt_en: New Broadcom ethernet driver.
From: Stephen Hemminger
...
> On Sat, 17 Oct 2015 00:21:44 -0400
> Michael Chan <mchan@...adcom.com> wrote:
>
> > +static bool bnxt_vf_pciid(int idx)
> > +{
> > + if (idx == BCM57304_VF || idx == BCM57404_VF)
> > + return true;
> > + return false;
> > +}
> > +
>
> I prefer just returning result of logical operation
> rather than adding unnecessary if statement.
> And never use (signed) int when unsigned is the real
> data type. Also avoid any unnecessary expansion of 16 bit
> value.
Actually 16-bit (and 8-bit) values always have to be extended to 'int'
before any arithmetic operations.
On systems with 16-bit arithmetic instructions (like x86) the
compiler can only use them if it can determine that result would be
the same (as if they were extended).
This can mean a lot of extra instructions if you do arithmetic
on 16-bit values the compiler is holding in registers.
Similarly using 16-bit values as function parameters/results
can require additional masking instructions.
IMHO This really all means that you should use [unsigned] int for
local variables even when the domain of the value is known
to be much smaller.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists