https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #19 from hubicka at kam dot mff.cuni.cz --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997 > > --- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > > > If I read it correctly, for a path that enters the loop and later leaves > > it (where threading is desirable since we skip the whole loop) the logic > > above will still return true (after finishing the whole walk which seems > > like a waste). > > Perhaps Richi can comment here, since this is his code? The testcase would be void test () { int i; if (test()) i=0; else i=100; for (;i<100 && bar ();i++) do_work (); } Here I think we can thread else path to return w/o any issues with loop nests even with -Os. > > > > > This may trigger more often at -Os since we limit loop header copying. > > Interesting. We have PR102906 which is a code size increase at -Os on ARM for > the same commit. I wonder if it's related. > > > > > And indeed, fixing profile updating would be nice. Why the updating > > code is not reused across different threaders? (I wrote several thread > > updating functions for varioius threaders introduced & remoed in the > > past and I wonder why we need to keep reinventing it) > > This all predates me. I don't know. For the record, both threaders use > completely different BB copiers and update mechanisms. It could be they're > sufficiently different that reusing it is unfeasible ??. Updating after trheading is not too hard however there is a painful point that profile may disagree with fact you proved. In general you do 1) you compute count of path your are threading (i.e. all edges you redirect to destination) 2) all BBs along the path needs to have this count subtracted since they are not going to be executed on it anymore 3) all conditionas on the path needs probabilities updated: you know the count entering the conditional and with same count you exit it via a particular edge. However here one needs to take into account that especially for guessed profiles (but for feedback too if code was duplicated earlier) the branch probability may be in a way that the leaving edge count is less than the count you want to subtract. Honza
