> Am 17.09.2018 um 19:11 schrieb Segher Boessenkool > <seg...@kernel.crashing.org>: > > On Mon, Sep 17, 2018 at 10:50:58AM +0200, Ilya Leoshkevich wrote: >>> Am 14.09.2018 um 23:35 schrieb Segher Boessenkool >>> <seg...@kernel.crashing.org>: > >>> Why does the existing jump threading not work for you; should it happen >>> at another time? >> >> We call cleanup_cfg (CLEANUP_THREADING) only once - during the „jump“ >> pass, which happens before combine. There is also „jump2“ pass, which >> happens afterwards, and after discussion with Ulrich Weigand I tried to >> move jump threading there. While this change had the desired effect on >> the testcase, the code got worse in another places. > > Yeah, jump2 is quite late. I think you should do it before postreload_cse > or similar.
Thanks, I will give it a try. > > Btw, what percentage of files (or subroutines) does jump threading run > after combine, with your patch? > I checked this on SPEC CPU 2006. Turns out it’s not as good as I expected: the additional jump threading is performed on 64% of the functions. I think this is because I only check whether PATTERNs have any side-effects, but I don’t look at INSN_CODEs. I'll try to change this and see whether I'll get a better number. Here are some other figures: - The total number of cleanup_cfg calls: +3.3%. - The total run time of cleanup_cfg: +5.5%. - The average run time of cleanup_cfg: +2.1%.
