[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b1427fb9-1ec1-a5b7-8f1d-9751d4d13b77@ieee.org>
Date: Wed, 22 Mar 2023 07:39:53 -0500
From: Alex Elder <elder@...e.org>
To: Julia Lawall <julia.lawall@...ia.fr>
Cc: Menna Mahmoud <eng.mennamahmoud.mm@...il.com>,
gregkh@...uxfoundation.org, outreachy@...ts.linux.dev,
johan@...nel.org, elder@...nel.org, linux-kernel@...r.kernel.org,
linux-staging@...ts.linux.dev
Subject: Re: [PATCH v2] staging: greybus: use inline function for macros
On 3/22/23 5:00 AM, Julia Lawall wrote:
>
> Both seem to access the memory directly. Maybe the example is too simple,
> and the compiler is more likely to optimize aggressively?
Yes I think so. This is a little unrelated but the
"inline" keyword isn't very useful because the compiler
(at least when optimizing) already takes liberties of
inlining code that it "knows" will be better done that
way. Same thing here. This function is so trivial
that it's almost certainly going to be inlined.
So the benefit of a little helper function like this over
a macro is that its types are specified explicitly, and
there is no chance of macro arguments be duplicated or
improperly used in the right hand side. If it's not
inlined it also would normally generate stuff on the stack.
The benefit of the macro is you can do things with the
arguments because they're pass-by-name. But you can't
expect there to be any efficiency benefit.
-Alex
Powered by blists - more mailing lists