Inline functions are implemented. As such, the stuff will get folded if the optimizer is running. Unfortunately, the earlier passes don't know it can be folded, so for example case values will produce an error message about not being constant.

Perhaps this can be improved so that functions that simply do a constant calculation get folded in the semantic phase rather than the optimization phase. This will avoid needing to change the language specification.

-Walter

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adu2u3$1gv1$1@digitaldaemon.com...
> Sometimes you need to have compile time constants (an enum perhaps.)  The situation I'm running into is D3D's definition of its HRESULT error codes. It uses a macro MAKE_D3DHRESULT to do the computation.  Aside from
expanding
> it out manually I don't think there's any way in D to have a reusable function-style package that generates compile time constants if given compile time constants as inputs.
>
> Surely the compiler could check when it expects a compile time constant
and
> instead encounters a function call, check if the function is inlineable
and
> the arguments are compile-time constants, and if so evaluates the function at compile time?
>
> Or is there some other way this can be automated?  I'd hate to duplicate that much code using copy'n'paste.  Copy'n'paste coding is the opposite of refactoring and is A Bad Thing.
>
> Sean
>
>

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

> Inline functions are implemented. As such, the stuff will get folded if
the
> optimizer is running. Unfortunately, the earlier passes don't know it can
be
> folded, so for example case values will produce an error message about not being constant.
>
> Perhaps this can be improved so that functions that simply do a constant calculation get folded in the semantic phase rather than the optimization phase. This will avoid needing to change the language specification.

   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.

Salutaciones,
                         JCAB

I would also like to have that same "power", although it would be even nicer if the compiler could warn when such an assertion would likely produce code-bloat / performance problems (though I recognise that's going to be complex)

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ae8g2c$1c7h$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ae8et9$1b1b$1@digitaldaemon.com...
>
> > Inline functions are implemented. As such, the stuff will get folded if
> the
> > optimizer is running. Unfortunately, the earlier passes don't know it
can
> be
> > folded, so for example case values will produce an error message about
not
> > being constant.
> >
> > Perhaps this can be improved so that functions that simply do a constant calculation get folded in the semantic phase rather than the
optimization
> > phase. This will avoid needing to change the language specification.
>
>    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.
>
> Salutaciones,
>                          JCAB
>
>
>

> Perhaps this can be improved so that functions that simply do a constant calculation get folded in the semantic phase rather than the optimization phase.

Perhaps it could be done, but it should be noted that it could have implications for a cross-platform compiler, because it cannot rely on its native types.

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

"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?

   Ok... I guess I asked for it :)

> Isn't that like using the 'register' keyword in C, and just as obsolete?

   I'll admit it is a control-freak's pacifier. With the perfect compiler,
it wouldn't be needed.

   Under ideal conditions, I would let the compiler do it. Problem is, I've
never seen a compiler get it consistently right. Maybe it's just me, after
all, I don't have that much experience with most compilers (including yours,
which I can't use for lack of enough C++ support). Visual C++ is
particularly bad, and it is the one I know best at this point. The thing is,
when coding, I often have things that I _know_ should be best inlined, so
I'd like to be able to tell the compiler to do it. Tell, not ask. Automatic
processing of data is a good thing that saves work from the human, but in my
experience it usually gets 80% short of the results of the human. Wether it
is program optimization, or 3D mesh tri-stripping, or voice recognition.
It's not reasonable to force a human to do all the processing, but still it
is a good thing to let the human provide additional information.

   A question: does the compiler do the inlining on the initial translation
phase, ot during final optimization?

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

   I guess I do agree on this. Would you say your compiler would be able to
satisfy me in this regard?

> (For debug compiles, it's nice to not inline anything, so that breakpoints
> on function calls work.)

   I totally disagree with you on this. I would really want some inlining on
debug builds, too. The problem of propagating a breakpoint on the function
to all the points where it got inlined, sounds no worse to me than, for
example, the problem of propagating it to all instances of a template.

   I guess that my main point of conflict in philosophy with you, Walter, is
that I prefer to put the burden of implementation in the program instead of
in the human who is using the program. Consider: things like ambiguities
hurt both, so they are bad to have in a language, but things like automatic
resource management help the human but make the program harder, so you seem
contrary to using them while I'm not. Maybe that's too much of a
generalization, but I do see this kind of pattern somewhere in there.

   In this case, I would want the compiler/debugger to be smart enough to do
the right thing while still allow inlining. It's harder, but it makes the
experience of debugging potentially better for the user.

   And while we're talking about philosophy, the other point of philosophy
that I embrace and you seem to avoid is leaving the (optional) power in the
user's (programmer's in this case) hands. If the programmer _knows_ he wants
a function to be inlined, I don't see why the language should get in the
way. I'm aware that you can't possibly foresee all possible things that the
programmer might want to express, but at least you shouldn't try to shy away
from those things programmers have already wanted to express in other
languages. This is something in which C++, with all its deficiencies, really
shines: even if a programmer cannot quite express something, maybe she can
make a library that lets her express it. The Spirit library (on
SourceForge), for one, is a clear example of this. Mind over language, so to
speak.

   All this is easy for me to say, of course. After all, it's not me the one
designng a new language implementing its compiler suite. :) Well, actually
it is, but I'm just doing it in my limited free time, starting with C++,
from scratch and without experience, so it's going super-extra-slow. I would
love to get into a discussion of language philosopy, design and
implementation, but that would be kind of off-topic here.

Salutaciones,
                         JCAB

JCAB

I think we have another opinion-piece for "The D Journal". Would you be prepared to write this note up as such, and submit it? I think it would provide some interesting reading ...

Matthew

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:aebmod$1o80$1@digitaldaemon.com...
> "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?
>
>    Ok... I guess I asked for it :)
>
> > Isn't that like using the 'register' keyword in C, and just as obsolete?
>
>    I'll admit it is a control-freak's pacifier. With the perfect compiler,
> it wouldn't be needed.
>
>    Under ideal conditions, I would let the compiler do it. Problem is,
I've
> never seen a compiler get it consistently right. Maybe it's just me, after all, I don't have that much experience with most compilers (including
yours,
> which I can't use for lack of enough C++ support). Visual C++ is particularly bad, and it is the one I know best at this point. The thing
is,
> when coding, I often have things that I _know_ should be best inlined, so I'd like to be able to tell the compiler to do it. Tell, not ask.
Automatic
> processing of data is a good thing that saves work from the human, but in
my
> experience it usually gets 80% short of the results of the human. Wether
it
> is program optimization, or 3D mesh tri-stripping, or voice recognition. It's not reasonable to force a human to do all the processing, but still
it
> is a good thing to let the human provide additional information.
>
>    A question: does the compiler do the inlining on the initial
translation
> phase, ot during final optimization?
>
> > 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.
>
>    I guess I do agree on this. Would you say your compiler would be able
to
> satisfy me in this regard?
>
> > (For debug compiles, it's nice to not inline anything, so that
breakpoints
> > on function calls work.)
>
>    I totally disagree with you on this. I would really want some inlining
on
> debug builds, too. The problem of propagating a breakpoint on the function to all the points where it got inlined, sounds no worse to me than, for example, the problem of propagating it to all instances of a template.
>
>    I guess that my main point of conflict in philosophy with you, Walter,
is
> that I prefer to put the burden of implementation in the program instead
of
> in the human who is using the program. Consider: things like ambiguities hurt both, so they are bad to have in a language, but things like
automatic
> resource management help the human but make the program harder, so you
seem
> contrary to using them while I'm not. Maybe that's too much of a generalization, but I do see this kind of pattern somewhere in there.
>
>    In this case, I would want the compiler/debugger to be smart enough to
do
> the right thing while still allow inlining. It's harder, but it makes the experience of debugging potentially better for the user.
>
>    And while we're talking about philosophy, the other point of philosophy
> that I embrace and you seem to avoid is leaving the (optional) power in
the
> user's (programmer's in this case) hands. If the programmer _knows_ he
wants
> a function to be inlined, I don't see why the language should get in the way. I'm aware that you can't possibly foresee all possible things that
the
> programmer might want to express, but at least you shouldn't try to shy
away
> from those things programmers have already wanted to express in other languages. This is something in which C++, with all its deficiencies,
really
> shines: even if a programmer cannot quite express something, maybe she can make a library that lets her express it. The Spirit library (on SourceForge), for one, is a clear example of this. Mind over language, so
to
> speak.
>
>    All this is easy for me to say, of course. After all, it's not me the
one
> designng a new language implementing its compiler suite. :) Well, actually it is, but I'm just doing it in my limited free time, starting with C++, from scratch and without experience, so it's going super-extra-slow. I
would
> love to get into a discussion of language philosopy, design and implementation, but that would be kind of off-topic here.
>
> Salutaciones,
>                          JCAB
>
>
>

"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 kind of disagree with this.  See below.

> I see the inlining issue as an overall speed/space tradeoff, something
that
> you'd specify with a global switch on the compiler.

Yes.  And for the most part that's what you want.

However I know from a fact that sometimes the &$*@% compiler vendors decide, in their infinite wisdom, to cause the compiler to not inline something for some reason that is based on flawed reasoning;  any reasoning that is not based on hard empirical evidence of execution flow and profiling is likely to be wrong, and can cost precious milliseconds in a game innerloop.

The programmer is infinitely better at deciding what absolutely must be inlined than the compiler is, so it is *very* handy to be able to force the stupid compiler to inline something that you know needs to be inlined than for the programmer to have no tool at their disposal to do anything about the speed problem.  It's not like we have macros to resort to, either;  At least in C++ we had those.  In D we'd have no choice but to copy and paste "manually inlined" chunks of code around to make sure they get optimized properly.  And that is *very* bad for maintenance reasons.  It's the opposite of refactoring, which is a very good thing.

Please give the programmer some way to control this.  At very least let it be a "strong hint" to the optimizer that this function should be inlined *if at all possible*.  Perhaps even in a debug build.  And same for "register" keyword in C;  many times that keyword was misused (along with "const" as a way to tell the compiler that there *will* be *no* aliasing on that value (register variables cannot have their address taken)).  I do not know of a compiler that can 100% verify whether a value is aliased and thus whether its value will change across a function call.  With "register" keyword we can assure the compiler it shouldn't worry about it and thus it's safe to optimize the value (leave it in a register, for instance).

I really think in the Real World (TM) programmers end up *needing* this level of control over the code the compiler produces.  Bitching at the compiler walter to get us an upgrade pronto that inlines better is usually not a viable option when deadlines are looming.

So please give us some kind of "optimize" or "inline" keywords or attributes to help the compiler do a better job of generating optimal code.  Not everyone can write a badass optimizing backend like you can.  ;)  But we still need to run on those platforms.

> (For debug compiles, it's nice to not inline anything, so that breakpoints
> on function calls work.)

Constant folding can still take place just not through inline function calls.

Some minor optimizations are possible in debug builds (ones that do not alter execution order at all).  In fact many times this is desirable (try debugging a debug build of the game that is running at 2 FPS, it is very hard to steer your guy around and reproduce game behavior.  But still easier than debugging the same problem in a fully optimized build)

"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?   ;)

Sean

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

> Inline functions are implemented. As such, the stuff will get folded if
the
> optimizer is running. Unfortunately, the earlier passes don't know it can
be
> folded, so for example case values will produce an error message about not being constant.
>
> Perhaps this can be improved so that functions that simply do a constant calculation get folded in the semantic phase rather than the optimization phase. This will avoid needing to change the language specification.

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! =)).

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