https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117935
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> --- Looking into optimization passes that might ignore predictors, only phiopt will ignore them and maybe remove them. And that is what is happening here. Other passes will keep them around. Jump threading, etc. will duplicate them as needed. phiopt is the only pass that totally ignores them and throws them away. Phiopt does not look through __builtin_expect so for early phiopt (which is before inlining) should not do what it is doing for explicit user provided predictors which is what the patch is designed for. For early return predictors, those can be ignored here most of the time you will have `if (a) return b; else return c;` so both sides will have a return predictor on it which we want to ignore since both sides return. Though having an user predictor does mean it might change code generation overall but I doubt it will be that much because like the case above, jump threading will already have optimized away the one if statement. There is not much code out there with user provided predictors yet either so doing benchmarking to see the effect overall will be hard.
