Hello,
What is the name of the conditional when we have inline on? I thought I can do {$IFDEF HASINLINE} but it doesn't work? Can you point me to some documentation please?
At http://community.freepascal.org:10000/docs-html/prog/progap7.html#x308-310000G I don't see conditionals for the inline option.

Also another question about inline:
In the attached test project when compiled with
fpc -XX -a test.pas small code is generated for the MyProc procedure that does nothing in this case (MORE_CODE is not defined). I do not uderstand assembler code very well but I see there some instructions when entering the procedure and when returning from it:

.type P$TEST_MYPROC,@function
P$TEST_MYPROC:
pushl %ebp
movl %esp,%ebp
leave
ret
.Le0:
.size P$TEST_MYPROC, .Le0 - P$TEST_MYPROC

Wouldn't it be a better optimization if the compiler does not generate any code? Any explanation and/or comments are welcome.

Greeting to all.
Alexander.

Hello Alexander,

If the "documented" compiler directive variable isn't working, I would just make my own so I only had to change one of code:

{$DEFINE USEINLINE}
{$INFO ============= }
{$IFDEF USEINLINE}
    {$INFO COMPILING WITH INLINE }
{$ELSE}
    {$INFO COMPILING WITHOUT INLINE }
{$ENDIF}

I have some code that has been commented as being very interesting for the compiler directives alone: http://www.jegas.org/?PAGE=main&SECTION=download

Try compiling test_uxxc_console.pas for example. You should do this at the command prompt so the compile window doesn't disappear on you or anything.

But NOTE: I use the += syntax, so you either have to add that construct to Your fp.cfg (or whatever file it is) or compile using the -Sc switch on the command line. (Enables += *= etc... which I use heavily)

I use conditional defines and {$INFO Blah blah} statements heavily - and it Comes in handy for dumping compile output to text files and searching for things - to see how a binary was compiled etc.

I hope this answers at least one of your questions.

Alexander Todorov wrote

What is the name of the conditional when we have inline on? I thought I can do {$IFDEF HASINLINE} but it doesn't work?

HASINLINE is simply a temporary internal compiler define which was introduced to indicate that the compiler supports the "inline" directive. It is not to be used your own code, since it will be removed from the compiler (it even has already been removed from 2.1.1, and may not even exist anymore in 2.0.4).

I don't think the compiler defines a symbol when inlining is turned on. As of 2.1.1, it won't matter anymore either since the compiler will always accept the inline specifier, but only actually do something with it if inlining is turned on.

That is not about inlining, but about stackframes. Stackframe optimization is implemented in 2.1.1 as well.

Jonas

on. As of 2.1.1, it won't matter anymore either since the compiler will always accept the inline specifier, but only actually do something with it if inlining is turned on.

Is there a way to know (in terms of $if etc.) that compiler actually does something?

Add {$inline on} to your source

Jonas

On Wed, 24 Jan 2007 10:49:07 +0100
Jonas Maebe wrote

Will there be a way to really know if inline is taken into consideration?

That is not about inlining, but about stackframes. Stackframe optimization is implemented in 2.1.1 as well.

Thanks for the answer.
I hope the next 2.2 release will have all these new features.

Greetings.
Alexander

Пётр Косаревский wrote

> Add {$inline on} to your source So I can be sure, that if it compiles, all inlines are implemented/ forced?

No, inline is and will always only be a hint. There are currently no provisions in the compiler which allow it to inform you in all cases where it does not perform the inlining (if you turn on warnings, it will warn for some cases).

Implementing it for all cases is non-trivial and has low priority.

Jonas

Actually, implementing the warning is easy, but always adding the reason why it isn't inlined is more difficult.

Jonas

I think, that there are many reasons, which will not help me a single bit.

However, reliable warning without explanations seems to be a good thing.

Reasons are e.g.
a) recursively calling an inlined procedure
b) a procedure containing an assembler block
c) calling an procedure which is declared inline before its implementation has been parsed (can be both because it's in another unit of which only the interface has been parsed, or in the current unit but the implementation has been parsed yet)

In the future, other less straightforward rules may be added as well (like "the compiler thinks the code would probably get slower rather than faster if this function is inlined").

However, reliable warning without explanations seems to be a good thing.

How? I think it's completely useless if you have no idea what it's caused by and what to do about it.

Jonas

Because I know, that I have to fiddle with program structure or something. One less reason to look into assembler code to see, what happens. (Of course, it concerns only time critical procedures.)