Re: [patches] Re: crossjumping speedups

[Jan Hubicka <jh at suse dot cz>]

> Hum.  Seems like it would be a win to delete these more
> aggressively then.
Just to note, that IMO cfg_cleanup is truly cheap now, as it uses the
CFG to avoid most of traveling of insn chain.

After your changes to crossjumping, that used to be implemented in rather
careless way, we now take 3% of compilation time for all cleanups done in
combine.c.  Original jump.c took considerably more.  So I would avoid doing
optimizations until we reach some testcases, where cfg_cleanup really is
expensive.

Current way of iterating over basic blocks and trying various
optimizations in order is IMO easy to understand and maitain.

Sure, it may be possible that we can construct testcase that forces
cfg_cleanup iterate too many times.  I will try to make one and see
how it behaves then.

On combine.c there are 50 places, where cfg_cleanup iterates 3 times,
20 where it iterates 4 times (in the crossjumping), 5 where iterates
5 times and 2 where iterates 6 times.

It shows that iteration is not problem in practice for now.

Still in the paradoxical cases, it may make sense to make crossjumping
smarter about updating cfg.  At the moment, in case block has matched
completely it creates forwarder, that is usually eliminated afterwards.

Originally I was avoiding this case, but it got too tricky to update
probability counts, so I gave up.  But it may make sense to call
try_forward_edges for each predecesor, once crossjumping is done and
then try to call try_crossjump_bb in those basic blocks to allow
chained crossjumping w/o iterating the main loop.

My tracer code heavily excercices crossjumper, as it works by doing
aggressive BB duplication on critical paths expecting crossjumper to
cleanup in cases where optimization didn't matched.

Honza