On 12/09/2015 09:47 PM, Segher Boessenkool wrote:
After shrink-wrapping has found the "tightest fit" for where to place
the prologue, it tries move it earlier (so that frame saves are run
earlier) -- but without copying any more basic blocks.
Unfortunately a candidate block we select can be inside a loop, and we
will still allow it (because the loop always exits via our previously
chosen block). We can do that just fine if we make a duplicate of the
block, but we do not want to here.
So we need to detect this situation. We can place the prologue at a
previous block PRE only if PRE dominates every block reachable from
it, because then we will never need to duplicate that block (it will
always be executed with prologue).
v4: Fixed all the stupid mistakes you noticed. Also, the previous
version stopped looking when the previous try didn't work out. This
version doesn't: it is simpler, more in line with the rest of the
algorithm, potentially useful, and doesn't really cost more.
Tested on the two testcases from the PRs. Also regression checked
on powerpc64-linux.
Is this okay for trunk?
Ok. This seems like a safe way to test things. For gcc-7 it might be
worthwhile to try to have loop information available and use that for
efficiency.
Bernd
