https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #23 from Jan Hubicka <hubicka at gcc dot gnu.org> --- I will implement the "allow size growth when there is a hot bb on a path" heuristics. We may try to get smarter on when the peeling actually helps the unpeeled path, but that is bit hard to do because there may be many threadable paths on the way (just as in the example) and we will never be able to fully judge optimization oppurtunities enabled by peeling (such as better VRP propagation, for example) I doubt being on aggressive side here will have large effect on code size. On unrelated note this testcase made me think that perhaps for -Ofast we want to adjust hot/cold heuristics so we are more aggressive on guessing that BB is hot as well (for -O2 we want to put into account code size implications, but for -Ofast we are probably permitted to drop them) Concerning peeling, we are probably always safe to decide to peel when the transformation decreases code size which is the case of all those early transforms I looked into (about 200-300 out of 700 on tramp3d). In fact such complete peeling ought to happen somewhere in the early pass queue. We can punt on non-size-decreasing peelings leaving them to dedicated pass. The loop peeling pass has its own way on predicting if something optimizes away. It does take into account induction variables but no phis that happens to be constant across the peeled path. Perhaps it should be merged with jump threader and the analysis part should be done in a common way. Backward threader should likely get smarter over time, taking into account, for example, the value ranges and this way both passes will benefit.
