[Top] [All Lists]

Re: [PATCH 1/2] Make stuff static

To: David Chinner <dgc@xxxxxxx>
Subject: Re: [PATCH 1/2] Make stuff static
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Mon, 16 Oct 2006 18:55:43 -0500
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, Timothy Shimmin <tes@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20061016232250.GM11034@melbourne.sgi.com>
References: <20060929032856.8DA9C18001A5E@sandeen.net> <23F15D6AE8566A54B81188AC@timothy-shimmins-power-mac-g5.local> <45338DDE.8020903@sandeen.net> <4533FAEA.2080500@sandeen.net> <20061016232250.GM11034@melbourne.sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
On Tue, 2006-10-17 at 09:22 +1000, David Chinner wrote:
> On Mon, Oct 16, 2006 at 04:34:34PM -0500, Eric Sandeen wrote:
> > Eric Sandeen wrote:
> > > Timothy Shimmin wrote:
> > >> Okay, started looking :-)
> > 
> > One other thing, based on the bug on osdl today, some of these larger
> > newly-static functions should probably be marked noinline to keep gcc
> > from doing things we don't want it to...
> <grumble>
> This is not an obvious compiler hint (compared to, say, likely()) as
> the functions gcc automatically inlines changes according to
> compiler version, optimisation level and platform. Hence adding
> noinline notation will be like playing whack-a-mole and I doubt it
> will be consistently used or maintained moving forward. It's the
> wrong solution, IMO.
> I think we should change the definition of STATIC so we don't have
> to poison the code to work around some stupid compiler behaviour.
> That is, unless we specifically say "inline" for static functions,
> we really mean "noinline".
So you are proposing?
/* non-debug */
#define STATIC static inline
/* debug */
#define STATIC noinline

That doesn't sound right that would inline everything that is static
which probably not a good idea in terms of stack usage.

#define STATIC static noinline
That doesn't work either ...
STATIC inline 
static noline inline?

> This will also make debugging easier because we won't get stack
> traces that are apparently missing functions and all the associated
> pain that this can cause.
> Thoughts?
> Cheers,
> Dave.
Russell Cattelan <cattelan@xxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part

<Prev in Thread] Current Thread [Next in Thread>