GCC Abstractions

[philberty]

The front-end was bootstrapped from GCCGO which abstracts GCC via backend.c. This really helped bootstrap the front-end but we may find maintaining the levels of abstraction to become very difficult over time. The goal for the project should really be to compile Rust for GCC first.

Personally I quite like many of the functions this abstraction has provided.

As a way to get a middle ground here what if we were to get rid of the abstract classes wrapping up gcc tree into Bexpression, Bstmt, etc, so that they simply return tree.

[tschwinge]

@philberty, I think we should do a proper decision here. ;-)

Given #805, we're going to use the core-GCC-specific tree in the GCC/Rust front end -- thus forfeiting your original stated goal of keeping the front end independent of GCC specifics (via the abstractions/wrappers that #805 is now removing). So are we now going all-GCC? Meaning, we can also get rid of other such abstractions/wrappers? (I'm fine with that for what it's worth.)

[tschwinge]

Here is one other thought. This came up outside of GCC/Rust, but now suddenly would be relevant here. ;-)

A few weeks ago I had the idea (which also has occasionally been discussed in GCC upstream, for at least two decades or so) that we may add some GCC-compile-time static typing to tree (which is just a union tree_node *), that is, replace the dynamically typed union [GTY] tree_node with a proper statically-typed C++ inheritance hierarchy, like we have for gimple, for example.

gccrs/gcc/coretypes.h

Line 97 in dcd7585

typedef union tree_node *tree;

gccrs/gcc/tree-core.h

Line 2021 in dcd7585

/* Define the overall contents of a tree node.

gccrs/gcc/gimple.h

Line 219 in dcd7585

/* Data structure definitions for GIMPLE tuples. NOTE: word markers

I did start looking into that, but it'll be slow, very slow. Per my assessment, given the expected volume of the changes, this needs to be done non-disruptively (and thus incrementally), directly is GCC master branch, with both the "old" and the "new" way co-existing for "a while". (... and first needs to be accepted by GCC upstream, of course...)

Now, the current GCC/Rust front end's Btype, Bexpression, etc. abstractions already are more specific than the generic GCC tree, and we're now proposing to get rid of the former via #805 -- just to then re-introduce such a thing if (IF!) my idea/project above becomes a reality. That will be a long time, however, and among all the other parts, the GCC/Rust front end will certainly not be the most difficult one for (re-)introducing such an abstraction/class hierarchy over the generic GCC tree. So that shouldn't stop us from now accepting #805?

So I think, what I'm asking for is your thoughts on this (or even if somebody -- ideally a bit more well-versed in C++ than I am ;-) -- is interested in helping work on this -- outside of the GCC/Rust context, directly in GCC upstream)?

[philberty]

@philberty, I think we should do a proper decision here. ;-)

Given #805, we're going to use the core-GCC-specific tree in the GCC/Rust front end -- thus forfeiting your original stated goal of keeping the front end independent of GCC specifics (via the abstractions/wrappers that #805 is now removing). So are we now going all-GCC? Meaning, we can also get rid of other such abstractions/wrappers? (I'm fine with that for what it's worth.)

Thanks, @tschwinge , I do like the idea of the abstractions, but there are three areas that are making me change my mind:

• The goal of GCC Rust has always been to make a GCC quality front-end for Rust.
  • This means this goal comes first before any long term goal of porting the code to new compiler platforms etc.
• The GCC IR is very suitable for further static analysis, and the abstractions will make this very awkward.
  • In the long term, we could potentially look at building a borrow checker at the GENERIC tree level, which might have some interesting code to share with wider GCC.
• Constant Folding
  • Const Generics will be very awkward until this is removed.
  • The abstraction requires features such as constant Folding, which does not fit very well right now.

So overall removing the abstraction is going to make some things much easier to work with. For example, in the short term, code generation for unions/ADTs/match-expr could be simplified a lot if we remove this. It also might help attract more GCC people to work with the backend code generation piece to clean up the code here.

[dkm]

It sounds a bit like the rtx type that was made more C++ by David Malcolm https://gcc.gnu.org/legacy-ml/gcc-patches/2014-08/msg00498.html . This can give a rough idea of the kind of work needed...

[bjorn3]

Would it be possible to keep separate types for things like Btype and Bexpression but implement an operator* and operator-> that derefs to the inner tree so you can directly operate on the inner tree but still keep some type safety?