This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Removal of gotos from cfg based ir
Hello,
> > > I am not quite sure what was the resolution of the discussion; anyway,
> > > here is the patch without the {COND,SWITCH}_EXPR ==> CF_EXPR change.
> >
> > My honest belief is that we end up with agreement that declaring CFG as
> > part of low level trees IL is good idea, so I really hope we will make
> > progress on this and get into job of doing real cfg_cleanup and CFG
> > manipulation infrastructure soon.
> >
> To date I have not seen a convincing argument supporting this IL
> change.
ummm. I believe Honza has sent a list with a long list of such arguments
in the thread; I don't want to repeat it here, since it should be easy
to find.
> Perhaps I missed it in the huge thread we had the other day.
> To me, the change is mostly eye-candy. When we decided to add a
> lowering pass for GIMPLE, it was to expose more details in the IL to
> make it more explicit. This is a step towards making some things
> implicit in the IL. It just doesn't feel right.
>
> To be convinced, I need to see concrete examples of common flow graph
> transformations that are more difficult or even impossible to do with
> our current representation. Code fragments, not code description.
There is of course nothing that would be impossible in the current
state; this is equivalent change. Just many things are easier, since
you have no problems of this type:
Say you want to do this simple cleanup to reduce the number of basic
blocks: you want to merge blocks A -> B if A has just B as successor
and B just A as predecessor. To do it, you must move B after A. To do
this, you must cleanup a fallthru edge from the predeccessor of B (if
there is any). Do do this, you may be forced to create a new basic
block. Oops, this somewhat contradicts the puprose of the cleanup...
> To me this whole thing can be hidden behind well defined redirect_edge,
> move_block APIs.
Yes, but this is ugly. Why the hell would we want to do the things the
hard way and hide it behind some cumbersome functions, when they can be
done easily? Note that even hiding the things behind the functions
won't help with things like necessity to create new blocks when
redirecting edges.
Zdenek