On 05/17/2013 02:53 PM, Steven Bosscher wrote:
On Fri, May 17, 2013 at 9:52 PM, Jeff Law <l...@redhat.com> wrote:
On 05/17/2013 01:49 PM, Steven Bosscher wrote:
Hello,
Trying to dump the CFG as a graph fails after the pro_and_epilogue
pass because it leaves unreachable basic blocks. This patch fixes that
issue.
Will commit sometime next week if no-one objects.
Ciao!
Steven
* function.c (rest_of_handle_thread_prologue_and_epilogue):
Cleanup the CFG after thread_prologue_and_epilogue_insns.
?!?
Under what conditions does threading the prologue/epilogue make code
unreachable?
Compiling testsuite/gcc.target/i386/pad-10.c with -fdump-rtl-all-graph.
Just before rest_of_handle_thread_prologue_and_epilogue we have:
Thanks.
What's happened, is that emitting the epilogue at the end of basic
block 4 (with a barrier at the end) has made the use insn 43
unreachable.
But from the description you've given, it appears that the epilogue
itself has unreachable code, and that shouldn't be happening. If you
think it can happen by way of shrink-wrapping, I'd like to see the analysis.
What does the epilogue itself look like before threading it into the
insn stream?
This reaction seems to me like an unnecessary and disappointing slap
on the wrist. Project policy does allow committing obvious patches
without review. Perhaps I should just use that policy and not give
people the chance to comment? I would think you would also know by now
that I know all CFG related code as well as anyone, and, frankly,
probably better than even you.
You do not make project policy. It's that simple.
Yes we have a obvious patch policy, but this certainly doesn't fall
under that policy. I would frown upon you using the obvious patch path
to bypass existing policy for patch review.
If you want commit without review privileges, ask for someone to sponsor
your request an the steering committee will vote on it.
jeff
