Go 1.22 Inlining Overhaul | Hacker News Reader

Go 1.22 Inlining Overhaul

docs.google.com

82 pointssigna1115 comments

I don't know if you have ever written an inliner, but it seems simple enough until you realise you are trying to restrain a rabid dog on a leash.

I wrote one a long time ago that was a part of a project that was moderately popular, but it had issues and incremental changes had a tendency to trigger weird edge cases. in the end someone with a CS PhD wrote a different one (while keeping quiet on the awfulness of my implementation) and it was so much nicer in every way. Reading his code was like reading poetry.

That was when I realised code should be deliberate. Every line is a step towards a goal. I think that is why rewriting something when you understand the problem domain better can be so liberating.

A good example on C and C++ code, is the UB that isn't there in first place, but gets triggered due to the way code is inlined, and suddenly the optimizer becomes aware of optimization opportunities that wouldn't be taken, if it wasn't for the code being inlined.

I'm not sure that I understand. A compiler inlining a function can't create undefined behaviour (UB) where there wasn't any before. Otherwise it would be breaking valid code.

Do you mean that after inlining the compiler has more visibility can can idenitfy UB that it was not sure was UB before?

An inliner should, by itself, never introduce a bug, except maybe inefficient code.

An inliner together with other optimizations can definitely lead to weird behaviour if you are not intimately familiar with the C spec.

Inlining can be a problem as it is the reason many other optimizations are being run. For example, I managed to recover "sensitive data" due to a DSR pass being run after inlining. The code worked fine at O1, but kept "sensitive data" ( not really, it was a programming course in HS where we broke eachothers programs) in memory at O2.

Edit: but yes, almost all of the time the problem is PEBKAC.

Yes, without inlining pass, there would be code in another function that wouldn't be visible, but after inlining the code structure changes, and a later optimizer pass sees e.g. a pointer check (which was inlined from another function), so now it can assume the pointer is never null and do its thing.

I wonder if a "release" build flag makes sense for go. There is so much optimisation potential left on the table for the sake of build time.

The current build should be "Dev" and a new "release" should be introduced.

Not bad, but build should default to release, and dev builds should be opt-in. You should never accidentally test against a non-production build.

It's a tough problem, because the situations in which fast build times matter are mostly during local development and test. Only at really insane scales do they become a problem for production releasing and CI/automated testing. An environment variable that can be set on a dev workstation globally (and overridden with CLI flags) would probably be sufficient for opt-in

What would have been bad about letting us annotate hot functions? My binary size is my problem.

All in all, looks like good ideas.

It looks convincing enough honestly

Anyone know what the "PGO" referred to in TFA is?

profile guided optimization https://learn.microsoft.com/en-us/cpp/build/profile-guided-o...

Better link in relation to Go: https://go.dev/doc/pgo

Reply on news.ycombinator.com