__attribute__((always_inline)) fiasco

__attribute__((always_inline)) fiasco

[Albert Cahalan]

> 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

Re: __attribute__((always_inline)) fiasco

[William Lee Irwin III]

On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> #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

The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
will cause spurious ignorance of the remainder of the line, which is
often very important. e.g.

static INLINE int lock_need_resched(spinlock_t *lock)
{
	...


-- wli

Re: __attribute__((always_inline)) fiasco

[Albert Cahalan]

On Thu, 2004-09-23 at 12:50, William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> > #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
> 
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)

Once you get over the initial jolt of seeing new syntax,
you'll find that C99 comments are clearly superior.

Even with block comments above functions, you'll typically
save two lines of screen space. (and 7 bytes)

I think the only trouble is assembly code abusing
the C (note: "C", not "assembly") pre-processor.

> will cause spurious ignorance of the remainder of the line, which is
> often very important. e.g.
> 
> static INLINE int lock_need_resched(spinlock_t *lock)
> {

Huh? Sure? It works for me:

albert 0 /tmp$ cat slash.c
#define MAIN main // test C99 comment
int MAIN (int argc, char *argv[]){
(void)argc;
(void)argv;
return 0;
}
albert 0 /tmp$ gcc -Wall -W -O2 slash.c
albert 0 /tmp$ ./a.out
albert 0 /tmp$ gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-linux/3.2.3/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc powerpc-linux
Thread model: posix
gcc version 3.2.3 20030415 (Debian prerelease)

Re: __attribute__((always_inline)) fiasco

[Richard Henderson]

On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> > #define INLINE static inline  // an oxymoron
...
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> will cause spurious ignorance of the remainder of the line, which is
> often very important. e.g.
> 
> static INLINE int lock_need_resched(spinlock_t *lock)

No it won't.  Comments are removed in translation phase 3;
macros are expanded in translation phase 4.


r~

Re: __attribute__((always_inline)) fiasco

[viro]

On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> > #define INLINE static inline  // an oxymoron
> 
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> will cause spurious ignorance of the remainder of the line, which is

Usual Albert's taste level aside, you are wrong.  Comments are replaced
with whitespace on phase 3 (tokenizer) and preprocessor lives on phase 4.
IOW, that // will never be seen by preprocessor.

Re: __attribute__((always_inline)) fiasco

[William Lee Irwin III]

On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
>> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
>> will cause spurious ignorance of the remainder of the line, which is

On Thu, Sep 23, 2004 at 06:21:04PM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> Usual Albert's taste level aside, you are wrong.  Comments are replaced
> with whitespace on phase 3 (tokenizer) and preprocessor lives on phase 4.
> IOW, that // will never be seen by preprocessor.

I'll be sure to put this on file with the rest of the numerous "while
legal in C, never *EVER* do this" oddities.


-- wli

Re: __attribute__((always_inline)) fiasco

[viro]

On Thu, Sep 23, 2004 at 10:33:15AM -0700, William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> >> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> >> will cause spurious ignorance of the remainder of the line, which is
> 
> On Thu, Sep 23, 2004 at 06:21:04PM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> > Usual Albert's taste level aside, you are wrong.  Comments are replaced
> > with whitespace on phase 3 (tokenizer) and preprocessor lives on phase 4.
> > IOW, that // will never be seen by preprocessor.
> 
> I'll be sure to put this on file with the rest of the numerous "while
> legal in C, never *EVER* do this" oddities.

Huh?  Comments (all sorts of comments) are dealt with before you get to
preprocessing.  Which *is* the right behaviour - anything else would be
much, much messier.  What's the problem with that?

Re: __attribute__((always_inline)) fiasco

[Tonnerre]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

Salut,

On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> > #define INLINE static inline  // an oxymoron
> > #define INLINE extern inline  // an oxymoron
> 
> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
> will cause spurious ignorance of the remainder of the line, which is
> often very important. e.g.
> 
> static INLINE int lock_need_resched(spinlock_t *lock)
> {
> 	...

Mmm, shouldn't the comments be filtered *before* the definition is set
in place? Just wondering...

			    Tonnerre

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: __attribute__((always_inline)) fiasco

[William Lee Irwin III]

On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
>>> #define INLINE static inline  // an oxymoron
>>> #define INLINE extern inline  // an oxymoron

On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
>> The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
>> will cause spurious ignorance of the remainder of the line, which is
>> often very important. e.g.
>> static INLINE int lock_need_resched(spinlock_t *lock)
>> {
>> 	...

On Sun, Sep 26, 2004 at 03:29:25AM +0200, Tonnerre wrote:
> Mmm, shouldn't the comments be filtered *before* the definition is set
> in place? Just wondering...

I've already heard more about this than I ever cared to. I'll continue
to stick to saner subsets of C and refuse to use things such as how the
preprocessor committing incest with the compiler proper (no, I don't
need it explained to me, it's trivial) allows crappy code to be written.
Don't lecture me; there's nothing to explain and I don't want to hear it.

-- wli

Re: __attribute__((always_inline)) fiasco

[Bill Davidsen]

William Lee Irwin III wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> 
>>>>#define INLINE static inline  // an oxymoron
>>>>#define INLINE extern inline  // an oxymoron
> 
> 
> On Thu, Sep 23, 2004 at 09:50:26AM -0700, William Lee Irwin III wrote:
> 
>>>The // apart from being a C++ ism (screw C99; it's still non-idiomatic)
>>>will cause spurious ignorance of the remainder of the line, which is
>>>often very important. e.g.
>>>static INLINE int lock_need_resched(spinlock_t *lock)
>>>{
>>>	...
> 
> 
> On Sun, Sep 26, 2004 at 03:29:25AM +0200, Tonnerre wrote:
> 
>>Mmm, shouldn't the comments be filtered *before* the definition is set
>>in place? Just wondering...
> 
> 
> I've already heard more about this than I ever cared to. I'll continue
> to stick to saner subsets of C and refuse to use things such as how the
> preprocessor committing incest with the compiler proper (no, I don't
> need it explained to me, it's trivial) allows crappy code to be written.
> Don't lecture me; there's nothing to explain and I don't want to hear it.

Don't hold back, tell us how you really feel ;-)

And I agree, those tricks shouldn't be used.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: __attribute__((always_inline)) fiasco

[Richard Henderson]

On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> Are benchmarks significantly affected if you remove the inline?

The routines in question expand to exactly one instruction.


r~

Re: __attribute__((always_inline)) fiasco

[Albert Cahalan]

On Thu, 2004-09-23 at 12:54, Richard Henderson wrote:
> On Thu, Sep 23, 2004 at 12:26:18PM -0400, Albert Cahalan wrote:
> > Are benchmarks significantly affected if you remove the inline?
> 
> The routines in question expand to exactly one instruction.

Fine, but that's not what I asked.

I asked if it shows up on benchmarks. It doesn't, does it?

Supposing that it does, then you might use the
alternate instruction replacement trick for this.
That will beat function pointers for speed.

Also, a simple conditional branch might be better
predicted than a function pointer anyway. At least
it will be close.

So you have at least four reasonable choices:

a. don't inline at all
b. have an uninline_foo() version for each foo
c. instruction replacement
d. simple conditional

The simple choices are better, unless you have
benchmarks (whole system ones) that show otherwise.

__attribute__((always_inline)) fiasco

[Richard Henderson]

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.

This attribute was invented to handle certain cases in <altivec.h>
and <xmmintrin.h> that contain assembly instructions that require
constant arguments.  These instructions *cannot* be emitted unless
the user of the function supplies a constant.  Which, under normal
usage situations is not a problem -- when the user doesn't give us
a constant, we error and that's the end.  But it does mean that 
the compiler is specifically *not* allowed to emit an out-of-line
copy of such a function, since there is in fact no way to legally
do so.

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.

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...


r~