On 01/12/2017 07:55 AM, Richard Biener wrote:
The following fixes PR77283, path splitting being overly aggressive
and causing loop unrolling not to happen (because how it distorts the
CFG).
It is a aim at creating a cost model (there's none apart from
not duplicating too much stmts) by means of the observation that
we'd have to have PHI nodes in the joiner to have any possibility
of CSE opportunities being exposed by duplicating it or threading
opportunities being exposed across the new latch. That includes
virtual PHIs for CSE (so any load/store) but not for the threading
(but IMHO threading should figure all this out on its own without
the requirement for somebody else duplicating the joiner).
Bootstrapped and tested on x86_64-unknown-linux-gnu, the s390x
libquantum regression is reportedly fixed by this. I had to adjust
gcc.dg/tree-ssa/split-path-7.c to not expect any path splitting because
I (and of course the cost model) can't see any reason to do it.
I went back and reviewed the discussion from last year. The conclusion
for linit (split-path-7.c) was that there was a path we could split, but
that there was no real benefit in doing so at the tree level.
The more general conclusion was that path splitting rarely exposes
CSE/DCE opportunities, contrary to the original motivation (the adpcm
encoder is the exception). What path splitting does more often is
remove an unconditional branch in diamond shaped sub-graphs.
In an ideal world, raw path splitting would move into the RTL pipeline
since it's primary value is to eliminate jumps and we'd use some kind of
PHI partitioning to handle cases where constant values from some paths
of control allow simplification at use sites. It's just path isolation.
I'll try to get to the rest of the review tomorrow tonight/tomorrow.
jeff
