* __builtin_expect vs. PGO @ 2011-12-21 7:53 Scott Meyers 2011-12-21 16:56 ` Ian Lance Taylor 0 siblings, 1 reply; 5+ messages in thread From: Scott Meyers @ 2011-12-21 7:53 UTC (permalink / raw) To: gcc-help What has more weight during codegen in a compilation with -fprofile-use when the code uses __builtin_expect to favor one branch while the PGO data says the other branch is more likely? Thanks, Scott ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __builtin_expect vs. PGO 2011-12-21 7:53 __builtin_expect vs. PGO Scott Meyers @ 2011-12-21 16:56 ` Ian Lance Taylor 2011-12-21 19:40 ` Scott Meyers 0 siblings, 1 reply; 5+ messages in thread From: Ian Lance Taylor @ 2011-12-21 16:56 UTC (permalink / raw) To: Scott Meyers; +Cc: gcc-help Scott Meyers <NeverRead@aristeia.com> writes: > What has more weight during codegen in a compilation with > -fprofile-use when the code uses __builtin_expect to favor one branch > while the PGO data says the other branch is more likely? I believe the probabilities will be combined in that case. The weighting of __builtin_expect is such that it will most likely be the predicted case, unless the profiling data says that the unexpected path is always taken. Ian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __builtin_expect vs. PGO 2011-12-21 16:56 ` Ian Lance Taylor @ 2011-12-21 19:40 ` Scott Meyers 2011-12-22 1:04 ` Ian Lance Taylor 0 siblings, 1 reply; 5+ messages in thread From: Scott Meyers @ 2011-12-21 19:40 UTC (permalink / raw) To: gcc-help On 12/21/2011 8:49 AM, Ian Lance Taylor wrote: > I believe the probabilities will be combined in that case. The > weighting of __builtin_expect is such that it will most likely be the > predicted case, unless the profiling data says that the unexpected path > is always taken. Thanks for the comment. The documentation for -fno-guess-branch-probability says: GCC will use heuristics to guess branch probabilities if they are not provided by profiling feedback (-fprofile-arcs). These heuristics are based on the control flow graph. If some branch probabilities are specified by `__builtin_expect', then the heuristics will be used to guess branch probabilities for the rest of the control flow graph, taking the `__builtin_expect' info into account. The interactions between the heuristics and `__builtin_expect' can be complex, and in some cases, it may be useful to disable the heuristics so that the effects of `__builtin_expect' are easier to understand. Is this is any way relevant? On the one hand, it's talking about heuristics to be used in the absence of profiling feedback, and I'm assuming we have profiling information. On the other hand, it's talking about the interaction of probabilities and __builtin_expect, and those probabilities presumably could come from PGO data. Scott ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __builtin_expect vs. PGO 2011-12-21 19:40 ` Scott Meyers @ 2011-12-22 1:04 ` Ian Lance Taylor 2011-12-22 12:15 ` Scott Meyers 0 siblings, 1 reply; 5+ messages in thread From: Ian Lance Taylor @ 2011-12-22 1:04 UTC (permalink / raw) To: Scott Meyers; +Cc: gcc-help Scott Meyers <NeverRead@aristeia.com> writes: > On 12/21/2011 8:49 AM, Ian Lance Taylor wrote: >> I believe the probabilities will be combined in that case. The >> weighting of __builtin_expect is such that it will most likely be the >> predicted case, unless the profiling data says that the unexpected path >> is always taken. > > Thanks for the comment. The documentation for > -fno-guess-branch-probability says: > > GCC will use heuristics to guess branch probabilities if they are > not provided by profiling feedback (-fprofile-arcs). These > heuristics are based on the control flow graph. If some branch > probabilities are specified by `__builtin_expect', then the > heuristics will be used to guess branch probabilities for the > rest of the control flow graph, taking the `__builtin_expect' > info into account. The interactions between the heuristics and > `__builtin_expect' can be complex, and in some cases, it may be > useful to disable the heuristics so that the effects of > `__builtin_expect' are easier to understand. > > Is this is any way relevant? On the one hand, it's talking about > heuristics to be used in the absence of profiling feedback, and I'm > assuming we have profiling information. On the other hand, it's > talking about the interaction of probabilities and __builtin_expect, > and those probabilities presumably could come from PGO data. Yes, by the time it matters in the compiler, probabilities are probabilities wherever they come from. The above paragraph is basically saying that in the absence of profiling information, the guessed probabilities are combined with the __builtin_expect probabilities. For a simple two-way branch I think __builtin_expect will always beat a guessed probabilities, just as it will generally beat a profiled probability. For something like switch (__builtin_expect (x, 1)) { case 0: ... case 1: ... case 2: ... } I'm not really sure what will happen. Ian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: __builtin_expect vs. PGO 2011-12-22 1:04 ` Ian Lance Taylor @ 2011-12-22 12:15 ` Scott Meyers 0 siblings, 0 replies; 5+ messages in thread From: Scott Meyers @ 2011-12-22 12:15 UTC (permalink / raw) To: gcc-help On 12/21/2011 5:02 PM, Ian Lance Taylor wrote: > Yes, by the time it matters in the compiler, probabilities are > probabilities wherever they come from. Makes sense, thanks. Scott ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-12-22 3:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-21 7:53 __builtin_expect vs. PGO Scott Meyers 2011-12-21 16:56 ` Ian Lance Taylor 2011-12-21 19:40 ` Scott Meyers 2011-12-22 1:04 ` Ian Lance Taylor 2011-12-22 12:15 ` Scott Meyers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).