> We need to rebuild frequency after vrp, otherwise the following code > in tree-ssa-threadupdate.c will make the frequency larger than > upper-bound. > > /* Excessive jump threading may make frequencies large enough so > the computation overflows. */ > if (rd->dup_blocks[0]->frequency < BB_FREQ_MAX * 2) > rd->dup_blocks[0]->frequency += EDGE_FREQUENCY (e); > > This is referring to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61384
I see, I still think C++ conversion gives us chance to turn both counts and frequencies to types that are safe WRT such calculations. Counts can be either software floats as discussed or fixed point 64bit type (I think we only need something like 8-10 bits to get problems Teresa is running into resolved - the cases where expanding statements gets sub 1 counts that needs to be diferent from 0) that does caps instead of overflow. Frequencies can be either the same or 32bit fixed point with capping as we do, sort of, now. I would really welcome if someone worked on this rather than papering around the bugs in current hand written fixed point arithmetics. (I am currently occupied by other projects, so I am not sure I can do it myself really soon) Honza
