This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa Too many edges in CFG


In message <1052409734.28441.2097.camel@p4>, Andrew MacLeod writes:
 >On Thu, 2003-05-08 at 11:58, law@redhat.com wrote:
 >> In message <1052408863.3648.2078.camel@p4>, Andrew MacLeod writes:
 >>  >On Thu, 2003-05-08 at 11:39, Jason Merrill wrote:
 >>  >> On 08 May 2003 11:21:02 -0400, Andrew MacLeod <amacleod@redhat.com> wro
 >te:
 >>  >> 
 >>  >> > That won't be good enough, we're going to need those copy-out operati
 >ons
 >>  >> > before all function call locations anyway
 >>  >> 
 >>  >> Indeed, most non-pure function calls could potentially cause the curren
 >t
 >>  >> function to exit abnormally via longjmp or throw.
 >>  >> 
 >>  >
 >>  >Or they could use the global, or re-enter a function with static
 >>  >locals... So the correct memory has to be stored to (and recovered after
 >>  >the call) if the variables hasn't coalesced with the correct memory
 >>  >location. Hoipefully that will be rare :-)
 >> But there's nothing to recover after a call to a nonreturning function.
 >> 
 >
 >No, but that non-returning function might use the value of the
 >global.... so it has to be right before the call is made. 
Right.  I've never said anything about what's done before the call.  
Clearly we have to have everything flushed to memory before the
call to the nonreturning function (or any other function for that matter).

My argument has been that:

  1. The edges shouldn't be necessary.

  2. If they are necessary for some of the algorithms in the compiler
     (or make the compiler more efficient in some way) then the edges
     should be marked as fake edges.

  3. Any code queued for insertion on fake edges can just be dropped as
     such code can never execute because a fake edge can never be
     traversed.

Jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]