April 03

On Saturday, 3 April 2021 at 10:32:18 UTC, Johan Engelen wrote:

>

On Friday, 2 April 2021 at 17:00:35 UTC, Steven Schveighoffer wrote:

>

On 4/2/21 12:27 PM, Johan Engelen wrote:

>

On Friday, 2 April 2021 at 14:40:00 UTC, Steven Schveighoffer wrote:

>

[...]

I'm pretty sure LDC will never give any warning or error on this pragma.
It will almost always inline the function into the caller (I don't know of cases where it can't).

So technically for LDC it will never encounter this case.

Pretty much.
When the function is recursive, it may prevent inlining.

>

Does LDC make any inlining decisions based on this flag?

Yes: the flag sets the alwaysinline attribute on a function, meaning that it will be inlined whenever possible, also at -O0.
https://d.godbolt.org/z/GEe8zxrro

-Johan

LDC will sometimes give up inlining on functions containing naked asm also, but there is a flag to tell LLVM that it's safe.

GCC has a similar set of flags, including @attribute("flatten") which inlines the called functions rather than the the function in it's caller.

April 03

On Saturday, 3 April 2021 at 12:04:18 UTC, Max Haughton wrote:

>

GCC has a similar set of flags, including @attribute("flatten") which inlines the called functions rather than the the function in it's caller.

Interesting!
Is this useful for anyone? We can implement something close to this fairly easily in LDC, but I'd rather wait until this LLVM PR: https://reviews.llvm.org/D70366

-Johan

April 03

On Saturday, 3 April 2021 at 20:29:59 UTC, Johan Engelen wrote:

>

On Saturday, 3 April 2021 at 12:04:18 UTC, Max Haughton wrote:

>

GCC has a similar set of flags, including @attribute("flatten") which inlines the called functions rather than the the function in it's caller.

Interesting!
Is this useful for anyone? We can implement something close to this fairly easily in LDC, but I'd rather wait until this LLVM PR: https://reviews.llvm.org/D70366

-Johan

I've used it maybe once or twice in some synthetic benchmarks - I'm not entirely sure, however being able to tune the optimizer (particularly the inliner) at source level without extremely ugly things like in C++ could be a huge win for the language e.g. the backend knows where to spend it's efforts (like in loops), but being able to spend more effort on some functions in hot loops is provably a win because you can see LLVM and GCC give up inlining in some examples on godbolt.

Next ›   Last »
1 2