[RFC] Design issues with multiple IRs

[RFC] Design issues with multiple IRs

[Diego Novillo]

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.

Re: [RFC] Design issues with multiple IRs

[Joseph S. Myers]

On Thu, 6 Dec 2001, Diego Novillo wrote:

> 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.

I don't see any need to use extra subdirectories for each internal
representation.  Subdirectories directly under gcc/ for front ends (with C
moved to such a directory) should suffice.

It is a bug when any tree-* files depend on any c-* files.  Enough
infrastructure for functions as trees should be language-independent that
such dependencies do not occur.

> 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-*?

C tree handling (in c/*.c, say) ought in principle to be lowering
C-specific trees to language-independent ones (with explicit ordering and
aliasing constraints represented in the latter).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [RFC] Design issues with multiple IRs

[Diego Novillo]

On Thu, 06 Dec 2001, Joseph S. Myers wrote:

> It is a bug when any tree-* files depend on any c-* files.  Enough
> infrastructure for functions as trees should be language-independent that
> such dependencies do not occur.
> 
OK.  I will rename the current tree-* files as they're mostly
C-specific.  I will also try and put the common code in tree-*.


> > 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-*?
> 
> C tree handling (in c/*.c, say) ought in principle to be lowering
> C-specific trees to language-independent ones (with explicit ordering and
> aliasing constraints represented in the latter).
> 
OK.  So, in the future, analysis and transformation passes done
on the language-independent trees would go into gcc/* together
with the RTL transformation passes, right?

Thanks.  Diego.

Re: [RFC] Design issues with multiple IRs

[Neil Booth]

Diego Novillo wrote:-

> 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-*?

When we create a c/ directory, I'd put C-specific stuff in there.  I
think the plan was to wait for 6 to 12 months to see if e.g.
subversion gets to a stable useable point, and maybe move to that
since it can move files properly.

> 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'd rather not have the ir directory; /tree and /rtl would be great.
Just MO.

Neil.

Re: [RFC] Design issues with multiple IRs

[Neil Booth]

Diego Novillo wrote:-

> 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).

Why not use a union?

If you give it a single letter, access is not so tedious, or wrap it
in a macro like we do now.  But if you can make even a bit of progress
on getting away from "everything is a tree" to "everything is a
pointer to a specific type" like we discussed the other day, that
would be great.

Neil.

Re: [RFC] Design issues with multiple IRs

[Diego Novillo]

On Thu, 06 Dec 2001, Neil Booth wrote:

> Diego Novillo wrote:-
> 
> > 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).
> 
> Why not use a union?
> 
That could be.  However, a union would increase the size of
*every* tree and basic block nodes.  We only allocate annotations
to very specific objects.

> If you give it a single letter, access is not so tedious, or wrap it
> in a macro like we do now.  But if you can make even a bit of progress
> on getting away from "everything is a tree" to "everything is a
> pointer to a specific type" like we discussed the other day, that
> would be great.
> 
I completely missed that thread.  Would you mind giving me a
pointer to it?  A quick search didn't produce anything
interesting.

Thanks.  Diego.

Re: [RFC] Design issues with multiple IRs

[Neil Booth]

Diego Novillo wrote:-

> I completely missed that thread.  Would you mind giving me a
> pointer to it?  A quick search didn't produce anything
> interesting.

The thread was "ICE in change_address at emit_rtl.c"; the first post
about pointers to explicit types was I think one of mine on 24th Nov.

Neil.

Re: [RFC] Design issues with multiple IRs

[Joseph S. Myers]

On Thu, 6 Dec 2001, Diego Novillo wrote:

> On Thu, 06 Dec 2001, Joseph S. Myers wrote:
> 
> > It is a bug when any tree-* files depend on any c-* files.  Enough
> > infrastructure for functions as trees should be language-independent that
> > such dependencies do not occur.
> > 
> OK.  I will rename the current tree-* files as they're mostly
> C-specific.  I will also try and put the common code in tree-*.

The right fix probably isn't to rename them (especially as the tree-dump
files were only just renamed from c-dump) - it's to make enough of
functions as trees language-independent that these files no longer include
C front end headers or call C front end functions, just using language
hooks for anything that genuinely is C/C++-specific.  Most of the
statement types used for C are probably suitable for being
language-independent.  (FOR_STMT is one that would be C/C++-specific if we
had tree lowering, but without tree lowering it isn't particularly worse
as a language-independent one than what we already have.)

> > C tree handling (in c/*.c, say) ought in principle to be lowering
> > C-specific trees to language-independent ones (with explicit ordering and
> > aliasing constraints represented in the latter).
> > 
> OK.  So, in the future, analysis and transformation passes done
> on the language-independent trees would go into gcc/* together
> with the RTL transformation passes, right?

I think that is appropriate.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [RFC] Design issues with multiple IRs

[Richard Henderson]

On Thu, Dec 06, 2001 at 10:11:37PM +0000, Joseph S. Myers wrote:
> The right fix probably isn't to rename them (especially as the tree-dump
> files were only just renamed from c-dump) - it's to make enough of
> functions as trees language-independent that these files no longer include
> C front end headers or call C front end functions, just using language
> hooks for anything that genuinely is C/C++-specific.

And indeed I believe that this must be addressed before anything
from the ast-branch may be merged to mainline.  Ideally we'd address
this on ast-branch *now* rather than continuing to push this off
into the indefinite future.


r~

Re: [RFC] Design issues with multiple IRs

[Diego Novillo]

On Thu, 06 Dec 2001, Richard Henderson wrote:

> On Thu, Dec 06, 2001 at 10:11:37PM +0000, Joseph S. Myers wrote:
> > The right fix probably isn't to rename them (especially as the tree-dump
> > files were only just renamed from c-dump) - it's to make enough of
> > functions as trees language-independent that these files no longer include
> > C front end headers or call C front end functions, just using language
> > hooks for anything that genuinely is C/C++-specific.
> 
> And indeed I believe that this must be addressed before anything
> from the ast-branch may be merged to mainline.  Ideally we'd address
> this on ast-branch *now* rather than continuing to push this off
> into the indefinite future.
> 
Absolutely.  That's why I wanted to ask for suggestions before I
kept doing changes to the branch.  I'm going to start looking at
language hooks.  What would be a good place to start looking for
examples?

Diego.

Re: [RFC] Design issues with multiple IRs

[Richard Henderson]

On Thu, Dec 06, 2001 at 10:31:06PM -0500, Diego Novillo wrote:
> Absolutely.  That's why I wanted to ask for suggestions before I
> kept doing changes to the branch.  I'm going to start looking at
> language hooks.  What would be a good place to start looking for
> examples?

I'd expect that you'd need little or nothing in the way of hooks.
I'd expect the language f.e. to build the function, translate any
language dependent nodes to language independent nodes, then pass
the whole thing off to you.

So I'd focus on the language independent nodes first.


r~