[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799
--- Comment #8 from Martin Liška ---
So what happens, pass_strip_predict_hints is called as last
pass_all_early_optimizations pass. That's called for first function. Then the
second one goes through einline pass, but in this time the first one is already
stripped. So solution would be to make pass_strip_predict_hints a simple IPA
pass and put it right after that. I have patch for that.
That would mean that following will not be striped before einline:
1) __builtin_expect (plus corresponding IFN) - it's fine
2) predict_exprs (and gimple_predict_exprs) - PRED_GOTO, PRED_CONTINUE,
PRED_FORTRAN_FAIL_IO, PRED_NORETURN, PRED_FORTRAN_WARN_ONCE,
PRED_TREE_EARLY_RETURN
Hope all are fine, maybe PRED_TREE_EARLY_RETURN is bit unreliable?
Honza what do you think? If you agree, I can make it IPA pass.
Having that, we'll have:
Predictions for bb 2
call heuristics of edge 2->4 (edge pair duplicate): 33.00%
call heuristics of edge 2->3 (edge pair duplicate): 33.00%
first match heuristics: 10.00%
combined heuristics: 10.00%
__builtin_expect heuristics of edge 2->3: 10.00%
Predictions for bb 3
1 edges in bb 3 predicted to even probabilities
Predictions for bb 4
1 edges in bb 4 predicted to even probabilities
Predictions for bb 5
1 edges in bb 5 predicted to even probabilities
inline_func_hint (bool b)
{
bool D.2307;
bool b;
long int _9;
long int _10;
[local count: 1073741825]:
_9 = (long int) b_3(D);
_10 = __builtin_expect (_9, 0);
if (_10 != 0)
goto ; [10.00%]
else
goto ; [90.00%]
[local count: 107374182]:
unlikely ();
goto ; [100.00%]
[local count: 966367642]:
likely ();
[local count: 1073741825]:
return;
}
[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Martin Liška --- (In reply to Jonathan Wakely from comment #6) > Using macros is not an acceptable solution for idiomatic C++. I see. Then let me really fix that.
[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 --- Comment #6 from Jonathan Wakely --- Using macros is not an acceptable solution for idiomatic C++.
[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 Martin Liška changed: What|Removed |Added Priority|P3 |P4 Status|ASSIGNED|NEW --- Comment #5 from Martin Liška --- Well, it would require partial stripping of selected predictors and then later stripping all of them after profile_estimate pass. About the __builtin_expect, I would recommend to use macro, similarly what Linux does: $ cat include/linux/compiler.h ... #define likely_notrace(x) __builtin_expect(!!(x), 1) #define unlikely_notrace(x) __builtin_expect(!!(x), 0) ... Thus lowering priority for the PR.
[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 --- Comment #4 from Jan Hubicka --- > I believe inlining is happening too late for it to have an effect - we are > early inlining a body which has the __builtin_expect replaced by nothing. > > Iff the expected outcome is "constant" a new function attribute would work. > For outcome dependent on context that wouldn't work. > > Not sure if we can simply introduce a return-value predictor that survives > inlining? Honza? with martin we added strip_predict_hints to the end of early optimization queue at https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01573.html this removes the hint and it is not used by the branch prediction of the outer function. The statement predictors are somewhat problematic here becuase they may associate with wrong conditional if the inner function body is optimized. I guess we have two options 1) do not re-do branch prediction on inlined code. 2) strip just selected hints and not others (like builtin_expect) that is safe even after inlning. Not sure which one is better... Honza > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- I can analyze that..
[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-05-16 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I believe inlining is happening too late for it to have an effect - we are early inlining a body which has the __builtin_expect replaced by nothing. Iff the expected outcome is "constant" a new function attribute would work. For outcome dependent on context that wouldn't work. Not sure if we can simply introduce a return-value predictor that survives inlining? Honza?
[Bug c++/85799] __builin_expect doesn't propagate through inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85799 --- Comment #1 from Mathias Stearn --- LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=37476
