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: <CAADnVQ+6-KQRRLS6Nos7u1J1BA9KoS6bJFAsnWE6d4vC010Djg@mail.gmail.com>
Date:	Wed, 14 May 2014 14:52: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 9:29 AM, Joe Perches <joe@...ches.com> wrote:
> On Wed, 2014-05-14 at 09:10 -0700, Alexei Starovoitov wrote:
>> from compiler point of view it's actually easier to deal with inline functions
>> than macros. I'd suggest to do the full conversion the other way around:
>> convert all macros to static inline. Developers will enjoy better type safety
>> and compiler will enjoy more opportunities to optimize code.
>
> Agree about the type safety, but sometimes a compiler will
> generate worse code with static inlines than #defines.

yep, sometimes compiler heuristics of size increase due to inline vs
cost of call
vs further optimizations after inline are guessing things wrong.
always_inline can force it in such cases.
Online articles about macro vs static inline mainly talk about
inlining and type safety.
I'm trying to make a point that there is more to it from compiler point of view.
'static inline' approach changes the scope of arguments whereas macro
pushes code into the scope of callsite.
Here is a synthetic example:
struct S {
  int v1;
  int v2;
  int v3;
};
static inline void f(struct S *s)
{
  s->v1 = 0;
  s->v2 = 0;
  s->v3 = 0;
}
#define F(s) \
  ({ \
     s->v1 = 0; \
     s->v2 = 0; \
     s->v3 = 0; \
   })

struct S *s1;
void test1()
{
  f(s1);
}
void test2()
{
  F(s1);
}
$ gcc -O2 -S  -fno-strict-aliasing
test1:
        movq    s1(%rip), %rax
        movl    $0, (%rax)
        movl    $0, 4(%rax)
        movl    $0, 8(%rax)
        ret
test2:
        movq    s1(%rip), %rax
        movl    $0, (%rax)
        movq    s1(%rip), %rax
        movl    $0, 4(%rax)
        movq    s1(%rip), %rax
        movl    $0, 8(%rax)
        ret

I cannot imagine the case where macro would be faster than static inline
unless it wasn't inlined.
--
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