[tree-ssa] Bootstrap fails with undefined reference to find_reachable_lable

[Steven Bosscher]

On Sat, 26 Apr 2003 16:33:41 +1000  Tim Josling wrote:
> > > - Restructure the c-* code and the back end to make a clean interface
> > 
> > Which is what GIMPLE effectively does (give you a clean interface from 
> > frontend to middle/backend), and since we are talking about the 
> > tree-ssa branch, you have GIMPLE.
> > 
> > You can simply generate GIMPLE trees directly from treelang, and be 
> > done with it.
> > If it doesn't work when you do this, something is broken, right Diego?
> > 
> > The G95 guys are using GIMPLE for their interface, too, aren't they?

Dan, if you're also among the confused and you actually mean GENERIC
then yes, we do.

> This sounds like very good news. I was aware of tree-ssa but not sure
> its status.
>
> Normally I make changes when something makes it into the mainline. Is
> that a bad idea in this case?

Well, tree-ssa code will not make it into mainline until 3.5 stage 1,
and this is the kazilloneth time that somebody experienced problems with
treelang on tree-ssa.

> In the meantime is there any
> documentation?

I was working on some GENERIC documentation, but I was told somebody
else was doing the same (never heard anything about that since, though),
and GENERIC is still experimental.  Also when I hacked up my text it was
still undecided which tree codes where absolutely necessary for
exception handling for C++.  So I decided to wait a bit until GENERIC
stabilizes somewhat.

Does anyone know which tree codes now make up GENERIC???

My understanding of the proposed interface is:

Input (some language)
|
|
| Front end for this language
|
V
Language-specific tree (not necessarily a GCC 'tree')
|
|
| Front-end specific "genericize"-pass
|
V
GENERIC (High-level, language-independent IR based on GCC 'tree')
|
|
| Language-independent "gimplifier"-pass
|
V
GIMPLE (Effectively a subset of GENERIC, low level IR for optimizers)
|
|
| Language-indepentend, tree based CFG/DFA/SSA builders and optimizers
|
V
Optimized GIMPLE tree
|
|
| Existing expanders in stmt.c and expr.c from tree to RTL
|
V
RTL

So the job of the front ends should be much easier:
- Easier to understand and more stable IR to work against.
- Less work to do: just parsing, semantic analysis, and
  building GENERIC tree that represents those semantics.

G95 does just that.

But to make it work right now you still depend on some of the c-*
files.  G95 depends on c-semantics, c-pretty-print, and c-dump.  You of
course also need dependencies on the tree-ssa framework.  Looks like
this for us:

F95_OBJS = list of the front-end specific files
F95_ADDITIONAL_OBJS = c-semantics.o c-pretty-print.o c-dump.o \
        tree-cfg.o tree-dfa.o tree-optimize.o tree-simple.o \
        tree-ssa.o tree-ssa-ccp.o tree-ssa-dce.o \
        tree-alias-common.o tree-alias-type.o gimplify.o

Maybe the mainline and tree-ssa treelang should be allowed to diverge. 
That way mainline treelang can stay as-is, but we can fix treelang to
fit in the tree-ssa framework.  This includes:
- making treelang build functions as trees (which it did not last
  time I looked)
- give it its own language-dependent 'tree' definitions
  (DEFTREECODE(whatever treelang needs that is not in GENERIC))
- give it its own genericize pass.

I'm willing to volunteer to maintain the separate tree-ssa treelang if
you don't have time for it.

Greetz
Steven