If you are relying on profile-directed optimization, the hints are almost surely redundant.
These are useful when there’s static knowledge about control flow that could assist the optimizer, e.g. with inlining decisions.
For example: It’s not uncommon to have “bi-modal” functions, where simple checks guard simple actions, followed by much more complex logic to handle everything else.
Are those checks for exceptional cases like an invariant violation? Think of an I/O write function confirming the device is open.
Or are they the “fast path” for the most common invocations? Think of std::vector::push_back() checking for available capacity.
The answer helps the optimizer immensely in deciding whether to “partially inline” the simple code into callers or not.
Sometimes the important performance critical path is the one least taken. You can't profile because the profiler has no way to know you don't care about the common path.
In general the profiler is a better tool, but there are rare exceptions and if those apply to you c++ gives you the control you need.
In my experience PGO is absolute garbage (for languages like C and C++). For complex programs all it does is bloat the code with no measurable benefit. And for every set of inputs where it improves performance there is another where it introduces slowdowns.
These are useful when there’s static knowledge about control flow that could assist the optimizer, e.g. with inlining decisions.
For example: It’s not uncommon to have “bi-modal” functions, where simple checks guard simple actions, followed by much more complex logic to handle everything else.
Are those checks for exceptional cases like an invariant violation? Think of an I/O write function confirming the device is open.
Or are they the “fast path” for the most common invocations? Think of std::vector::push_back() checking for available capacity.
The answer helps the optimizer immensely in deciding whether to “partially inline” the simple code into callers or not.