This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Andrew MacLeod <amacleod at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, jh at suse dot cz
- Date: Fri, 14 Nov 2003 13:00:15 -0700
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
- Reply-to: law at redhat dot com
In message <20031114070054.GD18752@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
>> >> I
>> >> understand there are benefits, but there are also negatives. Thats a bi
>> >> 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
>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.