netdev - Re: [PATCH net-next 0/5] bonding: simple macro cleanup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKvrL+eKNbV=OWP3h2qPmHDm5ixt_4qNDtw-DZeR8US-w@mail.gmail.com>
Date:	Wed, 14 May 2014 16:37:00 -0700
From:	Alexei Starovoitov <alexei.starovoitov@...il.com>
To:	Joe Perches <joe@...ches.com>
Cc:	Veaceslav Falico <vfalico@...il.com>,
	David Laight <David.Laight@...lab.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Jay Vosburgh <j.vosburgh@...il.com>,
	Andy Gospodarek <andy@...yhouse.net>,
	Veaceslav Falico <vfalico@...hat.com>
Subject: Re: [PATCH net-next 0/5] bonding: simple macro cleanup

On Wed, May 14, 2014 at 3:03 PM, Joe Perches <joe@...ches.com> wrote:
> On Wed, 2014-05-14 at 14:52 -0700, Alexei Starovoitov wrote:
>> I cannot imagine the case where macro would be faster than static inline
>> unless it wasn't inlined.
>
> For an example, look at commit 4153577a8d
> ("tg3: Use different macros for pci_chip_rev_id accesses")
>
> Converting these macros to static inline produces
> larger/slower code.  (at least with gcc 4.7.3)
>
> +#define tg3_chip_rev_id(tp)                                    \
> +       ((tp)->pci_chip_rev_id)
> +#define tg3_asic_rev(tp)                                       \
> +       ((tp)->pci_chip_rev_id >> 12)
> +#define tg3_chip_rev(tp)                                       \
> +       ((tp)->pci_chip_rev_id >> 8)
>

hmm. interesting.
Using gcc 4.7.2 object file size is larger with 'static inline'
2893016 vs 2868112
but that's due to larger debug info.
.text is actually smaller 000207c4 vs 00020824
and these three calls were inlined (even without __always_inline),
so I suspect it's better optimized..
though better optimized can very well mean slower.
--
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