This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa Too many edges in CFG
- From: Jason Merrill <jason at redhat dot com>
- To: law at redhat dot com
- Cc: Diego Novillo <dnovillo at redhat dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 08 May 2003 11:30:02 -0400
- Subject: Re: [tree-ssa Too many edges in CFG
- References: <200305081518.h48FIKXc004033@speedy.slc.redhat.com>
On Thu, 08 May 2003 09:18:20 -0600, law@redhat.com wrote:
> In message <20030508151341.GA14715@tornado.toronto.redhat.com>, Diego Novillo w
> rites:
> >On Wed, May 07, 2003 at 02:25:20PM -0700, Richard Henderson wrote:
> >> On Tue, May 06, 2003 at 08:50:06PM -0600, law@redhat.com wrote:
> >> > + /* Some calls are known not to return. For such calls we need to
> >> > + add an edge to the exit block. No fall thru edge is needed
> >> > + as these calls can not return in the normal sense. */
> >>
> >> Why do you need an edge to the exit block?
> >>
> >I don't think we use that for anything right now. In the future,
> >the predecessor blocks of EXIT_BLOCK_PTR will be the blocks where
> >we want to put copy-out operations for globals and statics.
> But for a non-returning function the edge to the exit block can never
> execute.
But a call to a non-returning function does in fact exit the function, just
not by returning to the caller. IIUC, the optimizers assume that any
non-dead code will be on some path between the entry and exit blocks. And,
as Diego says, if we've deferred copy-out operations we need to insert them
here, as a non-returning function can still refer to globals, and might do
a longjmp or throw to get back to our caller.
It would probably make sense to model it as an abnormal edge from the call,
much like EH.
Jason