What do we know about inlining except that the compiler will do it when it feels so?

Is there a guarantee that a simple macro-like definition like

   void MemClear(char *p,int size)
   {
      memset(p,0,size);
   }

will be inlined? What if this goes through multiple levels?

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

afaik, it is entirely up to the compiler, which is where it should be in almost all cases.

I think I remember there being discussion about the use of the inline keyword as something to _force_ the compiler to inline, which I kind of like, but maybe using that keyword is bad, since all the C++ programmers will use it everywhere, which may not be appropriate.

force_inline or forceinline might be better, as they're uglier, or even

forceinline
{
    void MemClear(char *p,int size)
    {
       memset(p,0,size);
    }
}

which would be unambiguous and quite obvious

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EA3AEB3.DDC28183@chello.at...
> What do we know about inlining except that the compiler will do it when it feels so?
>
> Is there a guarantee that a simple macro-like definition like
>
>    void MemClear(char *p,int size)
>    {
>       memset(p,0,size);
>    }
>
> will be inlined? What if this goes through multiple levels?
>
> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com

Why not inline(always), inline(prefer), inline(never), inline(SomeConstantComparedToStandardizedInlinabilityIndex)?
Like the way version already works?

Matthew Wilson wrote:
> afaik, it is entirely up to the compiler, which is where it should be in
> almost all cases.
> 
> I think I remember there being discussion about the use of the inline
> keyword as something to _force_ the compiler to inline, which I kind of
> like, but maybe using that keyword is bad, since all the C++ programmers
> will use it everywhere, which may not be appropriate.
> 
> force_inline or forceinline might be better, as they're uglier, or even
> 
> forceinline
> {
>     void MemClear(char *p,int size)
>     {
>        memset(p,0,size);
>     }
> }
> 
> which would be unambiguous and quite obvious
> 

Sounds ok to me

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:b81ms7$2vg8$1@digitaldaemon.com...
> Why not inline(always), inline(prefer), inline(never),
> inline(SomeConstantComparedToStandardizedInlinabilityIndex)?
> Like the way version already works?
>
> Matthew Wilson wrote:
> > afaik, it is entirely up to the compiler, which is where it should be in almost all cases.
> >
> > I think I remember there being discussion about the use of the inline keyword as something to _force_ the compiler to inline, which I kind of like, but maybe using that keyword is bad, since all the C++ programmers will use it everywhere, which may not be appropriate.
> >
> > force_inline or forceinline might be better, as they're uglier, or even
> >
> > forceinline
> > {
> >     void MemClear(char *p,int size)
> >     {
> >        memset(p,0,size);
> >     }
> > }
> >
> > which would be unambiguous and quite obvious
> >
>

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EA3AEB3.DDC28183@chello.at...
> What do we know about inlining except that the compiler will do it when it feels so?
>
> Is there a guarantee that a simple macro-like definition like
>
>    void MemClear(char *p,int size)
>    {
>       memset(p,0,size);
>    }
>
> will be inlined? What if this goes through multiple levels?

Think of inlining like the obsolete register keyword in C.

Whether obvious inlining is done or not is a quality of implementation issue, not a language issue.

>>
>> will be inlined? What if this goes through multiple levels?
>
>Think of inlining like the obsolete register keyword in C.
>
>Whether obvious inlining is done or not is a quality of implementation issue, not a language issue.

I agree, in the future most D compilers could have various compile-for-speed and compile-for-size switches for various environments ( ex: small embedded targets )

The design of the language should also allow for "Global System Analysis" see JOOP article May 2001 or look for similar info at http://smarteiffel.loria.fr/ http://smarteiffel.loria.fr/papers/papers.html

"Mark T" <Mark_member@pathlink.com> wrote in message news:b8bb7j$d7b$1@digitaldaemon.com...
> I agree, in the future most D compilers could have various
compile-for-speed and
> compile-for-size switches for various environments ( ex: small embedded
targets
> )

Yes.

> The design of the language should also allow for "Global System Analysis"
see
> JOOP article May 2001 or look for similar info at
http://smarteiffel.loria.fr/
> http://smarteiffel.loria.fr/papers/papers.html

D's design does allow for extensive inter-module analysis, although DMD makes no attempt at it.

On Thu, 24 Apr 2003 13:03:22 -0700, Walter <walter@digitalmars.com> wrote:
> Think of inlining like the obsolete register keyword in C.
> 
> Whether obvious inlining is done or not is a quality of implementation issue, not a language issue.

It'd still be nice to have a way of explicitly saying that a function either must or must not be inlined.  For example, the dynamic linker in the GNU libc will break if certain functions are not inlined, because the relocation has not yet been done.  The schedule() function in Linux will break on sparc (and perhaps some other platforms) if it is inlined, if you switch to a task that entered the scheduler via a different containing function.

As for the analogy with the register keyword, GCC extends that to allow you to explicitly place variables in specific registers, which is useful in conjunction with assembly code.  The uselessness of the original keyword does not mean that anything similar is also useless.

Neither of these are things you'd need very often, but when you do, it'd be really unpleasant if they weren't there.  After all, D claims to support "Down and dirty programming". :-)

-Scott

Who says the register keyword is useless?

I remember some case of some guys using a fairly recent GCC, where they could raise performance by 20% by putting in the simple register hint in a couple of spots. While the compilers are getting smart, they don't know anything particular about the program's typical input values, as the programmer usually does.

-i.

Scott Wood wrote:
> As for the analogy with the register keyword, GCC extends that to
> allow you to explicitly place variables in specific registers, which
> is useful in conjunction with assembly code.  The uselessness of the
> original keyword does not mean that anything similar is also useless.
> 
> Neither of these are things you'd need very often, but when you do,
> it'd be really unpleasant if they weren't there.  After all, D
> claims to support "Down and dirty programming". :-)
> 
> -Scott

"Scott Wood" <scott@buserror.net> wrote in message news:slrnbaoctt.3jp.scott@ti.buserror.net...
> On Thu, 24 Apr 2003 13:03:22 -0700, Walter <walter@digitalmars.com> wrote:
> > Think of inlining like the obsolete register keyword in C.
> >
> > Whether obvious inlining is done or not is a quality of implementation issue, not a language issue.
>
> It'd still be nice to have a way of explicitly saying that a function either must or must not be inlined.  For example, the dynamic linker in the GNU libc will break if certain functions are not inlined, because the relocation has not yet been done.  The schedule() function in Linux will break on sparc (and perhaps some other platforms) if it is inlined, if you switch to a task that entered the scheduler via a different containing function.

I suspect those functions are heavilly dependent on how a *particular* compiler generates code for that. Depending on that is going outside of the language definition. It makes successful operation of the code overly sensitive to particular compiler versions, etc. (Some linux kernel developers are open about the kernel code being heavilly dependent on how a particular revision of GCC generates code.) You could as easilly write code in D that depends on a particular implementation of D, though with D's support for inline assembler I'd argue that is unnecessary.


> As for the analogy with the register keyword, GCC extends that to allow you to explicitly place variables in specific registers, which is useful in conjunction with assembly code.  The uselessness of the original keyword does not mean that anything similar is also useless.

Those features are not part of the C language; although they are part of GCC, they will not work with every version of GCC, and will not work with any other C compiler. Contrast that with D, which has defined support for inline assembler. Try doing some inline assembler work in GCC, then with D. I think you'll find it supported far better in D, despite GCC's extensions.


> Neither of these are things you'd need very often, but when you do, it'd be really unpleasant if they weren't there.  After all, D claims to support "Down and dirty programming". :-)

Those things are what the inline assembler is for, and D has very strong support for inline assembler. The C language itself has no support at all for inline assembler, and GCC's support for it is very weak and error-prone (for example, there's an arcane syntax you have to add to say which registers were read and which were written by each asm block - get that wrong, and your code will behave unpredictably. D, on the other hand, keeps track of that automatically).