Hi,

With development fpc I get a lot of messages like:

fgl.pp(1112,1) Note: (3123) "inherited" not yet supported inside inline
procedure/function

Since most users can't do anything about the fgl inline modifier, this message dilutes the output.

IMO such a message should be off by default.

What do you think?

Mattias

The simplest solution is to remove the inline modifier, since it is clearly superfluous for that routine.

According to Florian, inline should not be used to begin with, since the compiler should be able to decide autonomously to inline a routine or not.

Michael.

Michael Van Canneyt via fpc-pascal
schrieb am Sa., 24. Juni 2023, 14:18:

I don't agree with Florian here cause the compiler detecting an inlineable routine that's declared in the interface section means an interface change after the interface section was already parsed and thus leading to the necessity to do recompilations which are already not working that well.

Regards,
Sven

Mattias Gaertner via fpc-pascal schrieb
am Sa., 24. Juni 2023, 13:12:

They are a reminder for us devs that these need to be fixed in the long term. If the messages are off by default *no one* will care about them. This way I least am reminded regularly that I want to give fixing them a try.

Regards,
Sven

That's merely an implementation problem:

It does not mean that Florian's concept is flawed, it just means the compiler is flawed.

In general, there is something to be said for the compiler determining what the optimal way is to use a given routine. It simply should not need such a hint.

Michael.

On Jun 24, 2023, at 7:18 PM, Michael Van Canneyt via fpc-pascal wrote: According to Florian, inline should not be used to begin with, since the compiler should be able to decide autonomously to inline a routine or not.

Doesn't this mean the compiler can dictate the binary size by inlining everything even if the programmer doesn't want that?

Regards,
Ryan Joseph

On Jun 24, 2023, at 10:11 PM, Hairy Pixels wrote: Doesn't this mean the compiler can dictate the binary size by inlining everything even if the programmer doesn't want that?

and another thing, I have frequent problems with a crash which happens in an inlined function and it's now not possible to step into the code in the debugger. Now I can disable the inline and step in the function but if it was auto inlined that would be really bad. Maybe the debug info could fix this though? It's a general problem with inlined functions anyway.

Regards,
Ryan Joseph

If we assume the compiler is really stupid, then such an outcome is possible.

But why would it want to inline everything ?

The idea of inlining is to optimize code. I assume that the compiler will be smart about it, and only inline when there is some gain to be had from inlining.

It seems to me no gain is to be had from e.g. inlining a routine of 500+ lines of code.

Presumably, in such a scenario the compiler commandline flags 'optimize for speed' and 'optimize for size' will then come into play when it needs to decide what to do.

Worst case scenario: there is a {$INLINE ON/OFF} directive which allows you to specify whether the compiler should even consider inlining or not.

Michael.

- You can disable inlining with a directive. One can envision that when compiling with debug info, no inlining is done.

- We're speaking about concepts. That the compiler's implementation has imperfections has no influence on the merits of the concepts themselves. It just means the implementation needs improvements.

Michael.

-O-
also afaik -Si-

{$INLINE OFF}

And, the compiler could write debug info were inlined code is. (Which then the debugger would also need to be taught to read)

On Jun 24, 2023, at 10:27 PM, Michael Van Canneyt via fpc-pascal wrote: It seems to me no gain is to be had from e.g. inlining a routine of 500+ lines of code.

What if the function was only called from 3 places in the program and each one of those was in something with very long loops, say 1 million iterations? If you inline you'd get only an extra 1000 lines of code size but save 3 million function calls which could be a big savings.

Regards,
Ryan Joseph

On Jun 24, 2023, at 8:37 PM, Sven Barth via fpc-pascal wrote: and thus leading to the necessity to do recompilations which are already not working that well.

Speaking of this, I've been including units in the implementation section and this often totally breaks the compilers recompilations.

In one project a change in a top level unit causes 2 exceptions in two different files. The solution is let the exception crash, save the file and rebuild. This mean a change to that file means you need to build 3 times before the program runs.

So already as it stands the compiler seems to not know which files changed and how to compile them in order, or something like that....

Regards,
Ryan Joseph

I doubt there will be any gain: 500 lines of code will result in many thousands of assembler instructions being executed 3 million times.

The few additional instructions generated by a function call are dwarfed by that.

More importantly: Inline is an automatism to optimize where possible.

You can always find exceptional cases which will not be handled by an automatism. They are irrelevant. It's the bulk of cases that needs to be solved by automatisms.

Michael.