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
- From: Chris Lattner <sabre at nondot dot org>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jan Hubicka <jh at suse dot cz>,Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,Diego Novillo <dnovillo at redhat dot com>,gcc-patches <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>
- Date: Fri, 14 Nov 2003 09:58:31 -0600 (CST)
- Subject: Re: [tree-ssa] Removal of gotos from cfg based ir
> > I do believe that approach of making CFG part of the IL (not making IL
> > uncomplette) is the most consistent sollution and probably easiest to
> > deal with. My next candidate would be the idea of shadow gotos, but I
> > would preffer to avoid it.
> IF you are entering a part of the optimizer where you are going to do
> this kind of manipulation a lot, why not simply change all FALLTHRU
> edges in the program to be explicit GOTOs until such time that you no
> longer need it? Is this what LLVM does? Its seems like the most natural
> way of dealing with the problem if its that sticky of an issue. then
> presumably cfg_cleanup will get rid of them all when you are done, if
> the blocks are indeed still consecutive.
In LLVM, all control flow (for both normal and exceptional control) is
represented explicitly in the program. For example, "fall-through" edges
are explicit gotos, which are eliminated during code generation. This
means that a code layout pass only needs to reorder blocks, it does not
need to modify the CFG or instructions _at all_.
An easy way to see what LLVM does to various programs is to try out the
online web form:
http://llvm.cs.uiuc.edu/demo/
Which will print out the LLVM code for any C or C++ translation unit you
give it.
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/