This is the mail archive of the 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 <>, 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.

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.

> Jeff

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