Do compilers take inline as a hint? | Hacker News Reader

Do compilers take inline as a hint?

blog.tartanllama.xyz

66 pointsEvgeniyZh21 comments

"Do The Right Thing And Measure It": words to live by.

This article has also reminded me of just how painful the main GCC codebase is. If you have a choice: Use LLVM for your compiler-hacking.

Well, I guess you could have tested whether or not the inline hint is used without looking at any source code at all: just find a suitable example program and see whether the executable changes after you compiled the program with or without any inline hints.

However, this bears the risk of being non the wiser in case your chosen program doesn't produce any differences in the compiled output: you wouldn't know whether it's because the compiler doesn't respect inline or whether the particular program you tried was for some reason not a good choice.

Depending on the simplicity of the program, the compiler may go ahead and inline it anyway!

My takeaway is the keyword's really just a hint anyhow. And that's borne out by the code dive.

I use it to show intent, as functions I mark as inline are those that, pre-C99, would have most likely been a macro. I prefer the inline function over a macro as it prevents a certain class of errors and you get some additional type-checking that macros lack.

Nice article! All the hours of arguing, testing or experimenting you can save by simply reading the only true source of information, the code. Wish more people would actually do this. I've seen people spending days trying to understand if a feature is supposed to be on by reading requirements or issue trackers, when a quick look at the code would tell you the answer in 30 seconds.

In the LLVM case you can see that PGO overrides the inline hint. And if you’re not using PGO you don’t care about performance that much anyway.

The best way to find out if your function was inlined is to build it as if for release and then disassemble and read it.

or you could just dump information from LLVM opt's inliner pass.

The inline keyword does not tell the compiler to copy and paste the function body into the caller. This is a misconception. It has semantic differences with where functions can be defined without causing duplicate symbol definitions. That is all.

Forced inline, on the other hand, is telling the compiler to copy and paste the function body. This will not always improve performance because code has interactions with the processor and memory/cache which make things more complicated.

> That is all.

Did you read the article?

I assume adding "inline" in front of a function declaration without actually defining it in the same compilation unit doesn't result in inlining. If this is true the article is wrong and the only important aspect about inline is how it affects the linker.

It may very well depend upon the tool chain. The Solaris C compiler/linker can inline external functions (a previous developer at my company relied upon that behavior when writing code), but that's the only one I'm familiar with that behavior.

I have lots of forceinline and always_inline in my code, but you can do too much of it, so always benchmark to be sure.

"The source for GCC is a fair bit less accessible than that of LLVM,... " - understatement of the weekend!

For more, there's Torvalds on GCC Inlining: http://yarchive.net/comp/linux/gcc_inline.html

This post is from 2000 and describes the old "gnu89" behavior of GCC which doesn't conform to C99.

Most of the mails are from 2008-2009

Warning: heavy lags on mobile while scrolling.

My anecdata: perfect scrolling, super smooth using stock browser on galaxy S7e.

Fine on iPhone 8 (Safari).

To add one data point concerning an "old" phone: smooth scrolling on Samsung Galaxy S4. At least with ads blocked.

Reply on news.ycombinator.com