Re: [PATCH v3] combine: perform jump threading at the end

[Segher Boessenkool <segher@kernel.crashing.org>]

On Tue, Sep 18, 2018 at 01:29:56PM +0200, Ilya Leoshkevich wrote:
> > 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%.

Thanks for all those numbers!

So IMO it is not worth doing this only _some_ of the time after combine,
given it doesn't help much and requires awful code, and awful code
duplication (setting state no less, eww).

It is also clear that jump threading indeed is quite a bit more expensive
than the average cleanup_cfg.

But it is also clear that in the grand scheme of things doing it always
does not cost much.

I wonder if it also helps on other targets to do an extra jump threading
(say right before postreload_cse)?  That would pretty much seal the deal
I'd say.


Segher