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
Go 1.22 Inlining Overhaul
11–19 of 19 posts
Re: Go 1.22 Inlining Overhaul
#12I 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.
Re: Go 1.22 Inlining Overhaul
#13[flagged]
Re: Go 1.22 Inlining Overhaul
#14What would have been bad about letting us annotate hot functions? My binary size is my problem.
Re: Go 1.22 Inlining Overhaul
#15I 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
Re: Go 1.22 Inlining Overhaul
#16[flagged]
None of these have any discussion and most barely have any upvotes. That is: it's not really a "duplicate".
Re: Go 1.22 Inlining Overhaul
#17I 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 imp…
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?
Re: Go 1.22 Inlining Overhaul
#18Earlier quoted context omitted.
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.
Re: Go 1.22 Inlining Overhaul
#19Earlier quoted context omitted.
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?
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.