On 11/02/2015 08:53 AM, Richard Sandiford wrote:
Steven Bosscher <stevenb....@gmail.com> writes:
On Fri, Oct 30, 2015 at 2:11 PM, Richard Sandiford
<richard.sandif...@arm.com> wrote:
Is the split_block change really so bad?
IMHO: Yes.
Fair enough :-)
I tend to agree. If the caller needs a more complex control flow and
dominance/post-dominance relationship set up, then it seems like it
belongs in the caller.
If there's enough commonality in cases where the caller is going to do
something more complex with the CFG, then perhaps there could be a
function to (as Richi suggests) create diamonds, half diamonds or
something else commonly needed.
I just thought that the cfg was in practice never going to stay in the
state that it is on return from split_block. The caller is bound to
add (at least) another edge somewhere.
Perhaps. But that functionality (assuming it's common) can be layered
on top of split_block pretty easily it seems.
Here's a version that works with split_block rather than against it.
Tested on x86_64-linux-gnu, arm-linux-gnueabi and aarch64-linux-gnu.
OK to install?
Thanks,
Richard
gcc/
* tree-call-cdce.c (shrink_wrap_one_built_in_call): Try to update
the dominance info; free it if we can't.
(pass_call_cdce::execute): Don't free the dominance info here.
OK.
Thoughts on emitting something into the dump file in tree-call-cdce.c
which indicates when the dominators/post-dominators are invalidated? Or
better yet, put it in free_dominance_info. Then we could have a
testcase which verifies that we're updating rather than recomputing in
the case which led to this change, and in cases where there's EH bits to
update that we recompute.
Jeff
