lkml.org 
[lkml]   [2004]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject__attribute__((always_inline)) fiasco
From
Date
> I'm displeased with someone's workaround for decisions made by
> the (rather weak) inliner in gcc 3.[123]. In particular, that
> someone doesn't understand all of the implications of always_inline.
...
> In the Alpha port I have a number of places in which I have
> functions that I would like inlined when they are called directly,
> but I also need to take their address so that they may be registered
> as part of a dispatch vector for the specific machine model.
>
> This scheme fails because my functions got marked always_inline
> behind my back, which means they didn't get emitted in the right
> place.

If it hurts, don't do that. It looks like bloat anyway.

Are benchmarks significantly affected if you remove the inline?
If so, simply have a second function:

extern void uninline_foo(void);
...
void uninline_foo(void)
{
foo();
}

> Rather than fight the unwinnable fight to remove this hack entirely,
> may I ask that at least one of the different names for inline, e.g.
> __inline__, be left un-touched so that it can be used by those that
> understand what the keyword is supposed to mean?
>
> Of course, there does not exist a variant that isn't used by all
> sorts of random code, so presumably all existing occurences would
> have to get renamed to plan "inline" in order to keep people happy..

Hey, I argued for INLINE when the static/extern changes
came along. That's the sanest, because one never knows
what the next annoying compiler will demand. Then you
can have one of:

#define INLINE
#define INLINE inline
#define INLINE static inline // an oxymoron
#define INLINE extern inline // an oxymoron
#define INLINE __force_inline
#define INLINE __attribute__((always_inline))
#define INLINE _Pragma("inline")
#define INLINE __inline_or_die_you_foul_compiler
#define INLINE _Please inline


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.371 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site