From: Brian Norris <computersforpeace@gmail.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
"u.kleine-koenig@pengutronix.de" <u.kleine-koenig@pengutronix.de>
Subject: Re: [PATCH 1/2] mtd: nand: force NAND_CMD_READID onto 8-bit bus
Date: Thu, 30 Jan 2014 12:47:56 -0800 [thread overview]
Message-ID: <20140130204756.GI8919@ld-irv-0074> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA6C85E@DBDE04.ent.ti.com>
On Thu, Jan 30, 2014 at 08:18:07PM +0000, Pekon Gupta wrote:
> >> >+static inline int nand_opcode_8bits(unsigned int command)
> >> >+{
> >> >+ return command == NAND_CMD_READID;
> >> >+}
> >> >+
> >> >
> >> Can 'nand_opcode_8bits, made a macro instead of inline function ?
> >> #define IS_8BIT_CMD(cmd) (unlikely(cmd == NAND_CMD_READID))
> >>
> >> Because 'nand_opcode_8bits' is used in nand_command() and nand_command_lp()
> >> which is performance critical code (chip->cmd is called multiple times for fetching
> >> page data and OOB). Though we should expect compiler to treat this inline function
> >> same as macro here, But just to be doubly sure for future changes also.
> >>
> >
> >I'm not a compiler guru, but I'd be very surprised if the compiler would make
> >a difference here, given the function is static, inline and small. Besides,
> >an inline function is more readable and type-aware. I'd say it's the Right
> >Thing to do.
> >
> >Nevertheless, I did a small check on my platform (handbuilt ARM GCC 4.7.2) and
> >both macro and inline is compiled into a "cmp" instruction. The unlikely
> >doesn't seem to have any effect.
> >
> Please check the JMP instruction just after CMP instruction..
> In-case of (unlikely(x == y)) JMP/JE will be used to branch when x == y.
> where as in-case of (likely(x == y)) JMP/JNE will be used to branch x != y.
...
> (this is my understanding, however may be for small branches this has
> no effect because both paths can be fetched simultaneously into pipeline).
With small branches, ARM just turns them into very compact conditional
instructions, rather than true branches.
This program generates identical code for functionA() and functionB()
when compiled with -O2 on ARM:
/* ------------- BEGIN PROGRAM ---------------- */
#define unlikely(x) __builtin_expect(!!(x), 0)
#define NAND_CMD_READID 17
#define NAND_OPCODE_8BITS(x) (unlikely(command == NAND_CMD_READID))
static inline int nand_opcode_8bits(unsigned int command)
{
return unlikely(command == NAND_CMD_READID);
}
int functionA(int command, int col)
{
if (nand_opcode_8bits(command))
return col;
return col >> 1;
}
int functionB(int command, int col)
{
if (NAND_OPCODE_8BITS(command))
return col;
return col >> 1;
}
/* ------------- END PROGRAM ---------------- */
Disassembly:
00000000 <functionA>:
0: e3500011 cmp r0, #17
4: 11a010c1 asrne r1, r1, #1
8: e1a00001 mov r0, r1
c: e12fff1e bx lr
00000010 <functionB>:
10: e3500011 cmp r0, #17
14: 11a010c1 asrne r1, r1, #1
18: e1a00001 mov r0, r1
1c: e12fff1e bx lr
Let's stop the nonsense then :) If you really want to pursue this, give me (1)
an example where they compile differently with (2) real, significant
performance differences. The burden is on you!
Brian
next prev parent reply other threads:[~2014-01-30 20:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 22:18 [PATCH 1/2] mtd: nand: force NAND_CMD_READID onto 8-bit bus Brian Norris
2014-01-29 22:18 ` [PATCH 2/2] mtd: nand: don't use read_buf for 8-bit ONFI transfers Brian Norris
2014-01-30 12:20 ` Ezequiel Garcia
2014-01-30 12:17 ` [PATCH 1/2] mtd: nand: force NAND_CMD_READID onto 8-bit bus Ezequiel Garcia
2014-01-30 18:00 ` Brian Norris
2014-01-30 19:17 ` Gupta, Pekon
2014-01-30 19:51 ` Ezequiel Garcia
2014-01-30 20:18 ` Gupta, Pekon
2014-01-30 20:47 ` Brian Norris [this message]
2014-01-31 6:55 ` Gupta, Pekon
2014-01-31 18:04 ` Brian Norris
2014-01-30 20:39 ` Brian Norris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140130204756.GI8919@ld-irv-0074 \
--to=computersforpeace@gmail.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox