This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
> 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.
I would ineed love to save CFG for inlining. We need be able to read
profile for whole program, do profile based inlining and update
profiling after the inlining operation.
I believe that this is best done if inliner works on CFG.
This is not easy change, but this is where I would like to get.