"Walter" <walter@digitalmars.com> wrote in message news:aeb9eg$1c72$2@digitaldaemon.com...
>
> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ae8g2c$1c7h$1@digitaldaemon.com...
> >    I've pushed for some thing like this before: allowing the programmer
to
> > specify that an inline function MUST be inlined instead of letting the optimizer choose. For constant expressions, that would be a really nice thing, too.
>
> Time for a philosophical question - why do you need to control whether a function is actually inlined or not? Isn't that like using the 'register' keyword in C, and just as obsolete? As long as the semantics are
maintained,
> inlining should be at the compiler's discretion, and how well it is done should be a quality-of-implementation issue.
>
> I see the inlining issue as an overall speed/space tradeoff, something
that
> you'd specify with a global switch on the compiler.
>
> (For debug compiles, it's nice to not inline anything, so that breakpoints
> on function calls work.)

If you *really* believe this, then your compiler should not impose any constraints on structures which require constant expressions, like case labels and static initializers.  These things should allow arbitrary expressions, involving variables and function calls, so long as they are computable at compile time.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aec4nf$279h$1@digitaldaemon.com...

> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:aebmod$1o80$1@digitaldaemon.com...
>
> >    A question: does the compiler do the inlining on the initial
translation
> > phase, ot during final optimization?
>
> I would rather it be done on initial translation, probably;  I guess right during semantic analysis at point of call.  Provided there were no bugs in the inlining algorithm (or that the vendor provides a way to turn off inlining in case there is a bug).  Of course the vendor will make sure there's no bugs in the inlining process, right?   ;)

   :-) I totally agree. Still, my guts tell me that it's usually done during
optimization or code generation. I just wanted Walter's take on it.

Salutaciones,
                         JCAB

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aec4nf$279h$1@digitaldaemon.com...
> "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:aebmod$1o80$1@digitaldaemon.com...
>
> >    A question: does the compiler do the inlining on the initial
> translation
> > phase, ot during final optimization?
>
> I would rather it be done on initial translation, probably;  I guess right during semantic analysis at point of call.

The inlining is done in a pass after semantic analysis but before optimization.

Generally, a function is inlined if it is below a certain threshold of complexity. The idea is short, simple functions get inlined, and large complex ones do not. In what circumstances would this not be what is desired anyway?

> If you *really* believe this, then your compiler should not impose any constraints on structures which require constant expressions, like case labels and static initializers.  These things should allow arbitrary expressions, involving variables and function calls, so long as they are computable at compile time.

Yes, you are right.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:aec67k$28u1$1@digitaldaemon.com...
> Another problem is, it heavily depends on the compiler capable of
> determining which functions perform constant calculations and
> which are not. So, you risk of writing the code which will compiles
> with DMD, but fails with GCC D (note: this was just an example! =)).

This can be consistent given a subset of the only thing a function references are its parameters and constants.

> In this thread, there was a suggestion of some form of macros support: a function with a body consisting of a single expression, defined using special syntax (so it's easy for any compiler writer to handle this case). It could serve both as a macro, and as a forced-inline function (since these should always be possible to inline)...

I think it's a crutch to do a special syntax where the regular function syntax will serve with a little more effort at the compiler implementation.

"Walter" <walter@digitalmars.com> wrote in message news:aee57a$1757$1@digitaldaemon.com...

> "Pavel Minayev" <evilone@omen.ru> wrote in message news:aec67k$28u1$1@digitaldaemon.com...
> > Another problem is, it heavily depends on the compiler capable of
> > determining which functions perform constant calculations and
> > which are not. So, you risk of writing the code which will compiles
> > with DMD, but fails with GCC D (note: this was just an example! =)).
>
> This can be consistent given a subset of the only thing a function references are its parameters and constants.

...and other such functions. Yes, you are absolutely right. But in 90% cases, it's just what we need. There are plenty of macros in API headers, like MAKEINTRESOURCE, which, on one hand, must be function (or at least look like a function), but, on other hand, is used in constant expressions.

> > In this thread, there was a suggestion of some form of macros support: a function with a body consisting of a single expression, defined using special syntax (so it's easy for any compiler writer to handle this case). It could serve both as a macro, and as a forced-inline function (since these should always be possible to inline)...
>
> I think it's a crutch to do a special syntax where the regular function syntax will serve with a little more effort at the compiler
implementation.

The problem is, it is not predictable, unless you define the rules which strictly describe whether the function is "const" or not, and require _all_ implementations to support inlining to this degree...

Because what *YOU* the compiler vendor think is an "acceptable" threshold for how simple it should be, may be too low, or too high.  In my experience it's too low; what I think is simple (say, an empty constructor or one that initializes a 4x4 matrix with identity) may be "too much" for the poor compiler to allow to be inlined.  A few critical sections of code may need inlining even though they exceed that arbitrary limit.  Sometimes, especially with later optimization and constant folding, sometimes the entire function just optimizes away, but the compiler wouldn't know that until it tried.  I would err on the side of inlining too much, since RAM is cheap and code caches are too small anyway.

Maybe if there is an inlining switch it could have a range setting, from low to high and in between.  However even "high" may not be enough in some situations.  So some quanta may be necessary.

Sean


"Walter" <walter@digitalmars.com> wrote in message news:aee4ke$16it$2@digitaldaemon.com...
> Generally, a function is inlined if it is below a certain threshold of complexity. The idea is short, simple functions get inlined, and large complex ones do not. In what circumstances would this not be what is
desired
> anyway?

I don't mind using special syntax to indicate to the compiler that something is very simple and should be treated as a "optimal" special case.  Such as a function that's completely compile-time deterministic (doesn't reference any external variables except constant ones nor any non-deterministic function). If you want to keep existing function syntax, then what we'd want instead is some kind of function attribute, am I right?

Sean

"Pavel Minayev" <evilone@omen.ru> wrote in message news:aeeln6$1men$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:aee57a$1757$1@digitaldaemon.com...
>
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:aec67k$28u1$1@digitaldaemon.com...
> > > Another problem is, it heavily depends on the compiler capable of
> > > determining which functions perform constant calculations and
> > > which are not. So, you risk of writing the code which will compiles
> > > with DMD, but fails with GCC D (note: this was just an example! =)).
> >
> > This can be consistent given a subset of the only thing a function references are its parameters and constants.
>
> ...and other such functions. Yes, you are absolutely right. But in 90% cases, it's just what we need. There are plenty of macros in API headers, like MAKEINTRESOURCE, which, on one hand, must be function (or at least look like a function), but, on other hand, is used in constant
expressions.
>
> > > In this thread, there was a suggestion of some form of macros support: a function with a body consisting of a single expression, defined
using
> > > special syntax (so it's easy for any compiler writer to handle this
> > > case). It could serve both as a macro, and as a forced-inline function
> > > (since these should always be possible to inline)...
> >
> > I think it's a crutch to do a special syntax where the regular function syntax will serve with a little more effort at the compiler
> implementation.
>
> The problem is, it is not predictable, unless you define the rules which strictly describe whether the function is "const" or not, and require
_all_
> implementations to support inlining to this degree...

> I don't mind using special syntax to indicate to the compiler that something is very simple and should be treated as a "optimal" special case.  Such as a function that's completely compile-time deterministic (doesn't reference any external variables except constant ones nor any non-deterministic function). If you want to keep existing function syntax, then what we'd want instead is some kind of function attribute, am I right?

Yes, right - the const attribute (since it cannot be applied to types anyhow). I just like that new syntax, makes it quite clear to the user that he's looking at a macro rather than some sort of function...