[RFC] Design issues with multiple IRs

[Diego Novillo <dnovillo at redhat dot com>]

We are now starting to write transformations using the tree SSA
pass.  There are some design issues that I'm not quite sure how
to address that I'd like to discuss before moving ahead:

Source code layout
------------------

Should files dealing with tree transformations go into a
different directory?  Right now, the trees are closely tied to
the front-end.  In the future I'd like to start introducing trees
that are more language independent.

For the current analyses and transformation I was thinking that
we could keep the current setup.  The tree-* files in the main
directory deal with the C front-end, each language directory
would need its own set of files.

But that doesn't fix the problem of what to do with common code.
We will likely have a lot of tree code that can be shared among
the different front-ends.  Maybe we should start putting common
code in tree-* and have C-specific files in c-tree-*?

Now, what happens when we start introducing trees that are
language independent?  Should we have another set of directories
for each IR?  I haven't thought this through, but initially I can
picture something like this:

  gcc
  |
  +-> fe
  |    +-> c
  |    +-> cpp
  |    +-> java
  |    ...
  |
  +-> ir +-> tree (these would be language independent trees)
  |      +-> RTL
  |
  +-> config +-> ...

I have glossed over lots of details and it's just an initial
idea.  Essentially, I'd like to split the sources across the
front-end and IR axes.  Common code could go in the main
sub-directories.

I think I've seen this discussed elsewhere, but I can't find the
thread.  Could someone point me to it?


Common code between different IRs
---------------------------------

We have started running into situations where the different IRs
may benefit from sharing common code (Jan's CFG routines,
Daniel's SSA-CCP pass).

Sharing common code between IRs may involve using callbacks,
which will typically need a void pointer to access IR objects.
I'm not particularly fond of this idea.  I'd like to have the
notion of a generic IR class that we could sub-class.  Maybe
having an IR that is laid out in the same way as trees and RTL?

Another place where we are abusing void pointers is in
annotations attached to flowgraph nodes and trees.  The 'aux'
fields are being used to hold analysis information.  For
instance, trees use the 'aux' pointer to hold a pointer to the
basic block that contains the tree (only for statement trees), a
pointer to a list of references for VAR_DECLs, a pointer to the
most recent definition of a VAR_DECL (for building the SSA web).

Similarly, basic blocks contain various annotations that are
added when building the flowgraph.  I'm looking for alternatives
to this setup.  I'm not sure that having void pointers is such a
good idea.  Particularly since one has to be careful when there's
the possibility of sharing (eg, non-statement trees).

Probably this information could be contained in tables.  Either
hashed or indexed by some object ID.  With RTL we can keep track
using the insn id.  Maybe we should add something similar to
trees?

Any other issues?  Thoughts?

Thanks.  Diego.