Add keyword to support inlining across modules

[dalon-work]

The idea is pretty simple: Allow marking public module functions/subroutines with a keyword such as 'inline' or 'export'. This requires the compiler to place the implementation, and not just the interface of the subroutine in the binary module file. Modules that use this 'inlined' module will be able to see the implementation of the subroutine and potentially inline it. The decision to inline or not is left up to the compiler.

This would replace many uses of #include for performance reasons, and would have the greatest benefits for small functions where the function call overhead is comparable to the actual work of the function.

This would give us the benefits of modules, while still allowing an important optimization that fortran currently misses, and removing a preprocessor peril.

You could argue that Link-Time Optimization has already made this idea obsolete, but I'm not convinced LTO has become ubiquitous?

Thoughts?

[certik]

On this theme, LFortran currently places all implementations in the mod file, precisely so that they can be inlined later on. I strongly suspect inlinging at link time is too late, I think the best way is to inline at the "Fortran level". I don't know yet however if it is sustainable to include all implementations in the mod file, or whether we should only include those that the user selects using the "inline" keyword (alternatively the compiler could always include just those functions that are candidates for inlining, skipping large functions). But I will know the answer once we can compile large production codes, probably in a year or so.

[zerothi]

I would prefer not going this path.
C++ and other languages has tons of these features, while these are good shortterm C++ is now becoming a beast with so many additional keywords that does this and that. It effectively becomes too hard to understand the code (something I think fortran is trying to maintain, and should).

I agree that inlining would be nice, but I am afraid this will fill fortran code with official and non-official keyword extensions.

[perazz]

I was about to suggest the same feature and I found it was proposed already so I'm going to give it my additional "thumbs up" here.

I see most of the features for F202Y are making it converge toward being "C++-like" and this would be no stranger,
but I believe one of the major (only?) reasons people are still coding Fortran besides backward compatibility is SPEED.

Being able to inline functions across modules at compile time is very strongly needed IMHO because, with all modern structures like classes, modules, submodules, code goes scattered across files and the impossibility to do compile-time inlining across them is a very severe limitation that can make Fortran much slower than C/C++.

Consider this example: Having a very basic module/class for 3D points, with some very simple overloaded operators:

type :: vec3
   real(real64) :: x,y,z
   contains
      procedure, private :: vec3_sum_vec3
      generic :: operator(+) => vec3_sum_vec3
end type vec3 

contains

elemental type(vec3) function vec3_sum_vec3(a,b) result(c)
   class(vec3), intent(in) :: a,b
   c%x=a%x+b%x
   c%y=a%y+b%y
   c%z=a%z+b%z
end function vec3_sum_vec3

Function vec3_sum_vec3 is going to get called a gazillion amount of times across any code that makes usage of this class; yes, the class could be extended, so the inline feature could be prescribed in all inherited variants.

[FortranFan]

Fortran 202X introduces SIMPLE procedures that can also be ELEMENTAL.

The vec3_sum_vec3 example in the post above is in principle a simple procedure; starting Fortran 202X, it can be CLAUSEd as such. This can be a clear indication to the compiler such a procedure can be inlined if the compiler can estimate a benefit with it.

If a procedure is not simple or even pure, chances are rather high inlining will prove costly.

Thus a question for @certik and everyone with compiler development expertise: can the already available CLAUSEs such as SIMPLE (and ELEMENTAL, and perhaps even PURE) be the "clues" for compilers here for greater performance and optimization? That is after all also the purpose of these CLAUSEs.

Why introduce any additional keywords into the language?

[perazz]

I agree there's too many function clauses already and that the philosophy is to leave the compiler "do the hard work";

I guess my point on inlining was about forcing the compiler do it instead of just allowing it,
I believe any other SIMPLE/PURE clauses could be a prerequisite to it.

Another way to achieve this behavior could be to force type-bound procedures being included in the module file?
That would nicely connect to old-style file inclusion, and would not require new keywords. Think of something like:

type :: vec3
   real(real64) :: x,y,z
   contains
      procedure, include, private :: vec3_sum_vec3
      generic :: operator(+) => vec3_sum_vec3
end type vec3 

Or, on a procedure interface:

module vec3_m

public, include :: vec3_sum_vec3

[...]

[certik]

I think that this is something that we should implement in a compiler and experiment with before we propose it. In C++ the inline keyword is not forcing the compiler to inline it either. So from that perspective, the simple or pure keyword can act in the same way.

We could also introduce an inline keyword that will force the compiler to always inline, and we can experiment with it. LFortran has a function inlining optimization (prototype so far) and I think it can inline across module boundaries, as the compiler sees the whole code. We still have to implement criteria when the function should be inlined. Typically some kind of heuristics.

As a user, I think I would like to be able to tell the compiler to always inline a certain function.

[gklimowicz]

Fortran 202X introduces SIMPLE procedures that can also be ELEMENTAL.

...

If a procedure is not simple or even pure, chances are rather high inlining will prove costly.

Thus a question for @certik and everyone with compiler development expertise: can the already available CLAUSEs such as SIMPLE (and ELEMENTAL or perhaps PURE) be the "clues" for compilers here for greater performance and optimization? That is after all also the purpose of these CLAUSEs.

I favor this tactic. I would like to see this level of inlining treated as a "quality of implementation" issue until we have more formal experience with it. (My uninformed guess is that some compilers already do the inlining.)

[klausler]

Suggestion: if a keyword be added (INLINE or whatever), have it imply some semantics. Some things can be difficult to handle in a compiler when inline expansion is taking place, and a keyword would prohibit their use in a subprogram in a way that is analogous to the restrictions that one accepts when using PURE or DO CONCURRENT. An obvious item on that list would be to prohibit local objects with the SAVE attribute (explicit or implied).

[dalon-work]

Thanks everyone for the interest!

What I've found most interesting in this conversation is that the LFortran compiler places implementations in the binary module file by default. Do other compilers do that?

The closest analogue to my original request that I know of is in the new C++20 module system. If a templated function is 'exported', then the entire body of the function has to be placed in the resulting binary module file so the function can be instantiated later. The C++ standard doesn't speak of the actual implementation details, so it is unclear if the definition of a non-templated function will end up in the binary module file. There seems to be, IMHO, an unspoken expectation by those who write/speak about C++20 modules that this will be the case.

As for forcing inlining, most languages I know have some mechanism for doing so, but it's never at the language level. It's always some sort of compiler-specific thing.

C/C++ - every compiler as their own way of specifying it
Julia - @inline macro
Rust - #[inline(always)] function attribute - (works across crate boundaries!!)

Since Fortran likes to leave things up to the compilers, perhaps this discussion will at least encourage compiler writers to do this optimization for 'small' functions so they can be inlined across module boundaries.

For those compilers that choose not to do this optimization, there is always LTO...

[certik]

What I've found most interesting in this conversation is that the LFortran compiler places implementations in the binary module file by default. Do other compilers do that?

I think the Zig compiler also has access to all the code when compiling the main program, unless I am mistaken.

[perazz]

I'm no expert in assembly code, but I've entered my example in godbolt and it looks like:

• gfortran 11.3 (older ones look similar) will inline both scalar and array versions of the function with -O3; with -O2, only the array version is inlined
• vec3_sum_vec3 is inlined even if it's got no elemental or pure clauses.
• ifort 2021 seems to always inline.

I couldn't put the module in a physically separate file from the main program there, that would have tested the exact scenario I am referring to.