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] Removal of gotos from cfg based ir


In message <20031114070054.GD18752@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
 >Hello,
 >
 >>  >> I
 >>  >> understand there are benefits, but there are also negatives. Thats a bi
 >g
 >>  >> enough switch that we're almost handling 2 ILs in my books.
 >>  >
 >>  >Could you be more specific about the negatives? I fail to see any.
 >> First and foremost the IL is no longer a complete representation of the
 >> program.  To me that seems like the wrong direction from a design standpoin
 >t.
 >
 >it is not now,
Err, yes it is.  We can derive all the EH state for the CFG from the IL.  At
least that's the way it used to work, and I serious doubt Richard's changes
changed that fundamental concept.

 > either; to do exception handling, you must use such a kind
 >of information.  And in fact, IL == statements + cfg even now -- you
 >cannot reach statements without passing through basic blocks.
You're confusing things badly.

The IL is all we need to represent a function -- we derive auxiliary
data from that IL -- for example, we can derive a CFG from that IL. 

With your change the IL is no longer sufficient to represent the program.
So for example, you either have to save the CFG for inlining or you have
to run through the CFG and insert jumps before you save the IL for inlining.

Jeff




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