RFC: gimple.[ch] break apart

[Diego Novillo]

On Wed, Oct 30, 2013 at 10:26 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> I've made 4 attempts now to split gimple.[ch] into reasonable component
> parts, and I've finally found something that I can make work and fits my
> plans.
>
> I've attached a diagram to (hopefully :-) clarify things.

That's not a class hierarchy diagram, right? I'm not sure what it
illustrates. What are the arrows? The dotted arrows?


> I'd like to move these as I encounter them into a new file,
> gimple-decl.[ch].  When I'm working on the other gimple classes, this will
> be further split into gimple-decl, gimple-type and gimple-expr as
> appropriate but it seems reasonable to create just the one file now to clump
> them since there is no other formal organization. So any function which is
> actually querying/setting/building a decl, type, or expression for gimple
> would go here.

Sounds reasonable.

> I also want to split out the structure and accessing bits of the gimple
> statement structure into gimple-stmt.[ch].  This would be just the struct
> decls as well as all the accessing/setting/building functions...

Right.

> The gimple_stmt_iterators (gsi) themselves also break out into their own
> file quite naturally.
>
> I find that gimple_seq does not seem to be a very clearly defined thing.
> Although a gimple_seq is just a typedef for a gimple stmt (I thought it use
> to be a container?), it provides some additional statement queuing

It used to be a proper container, yes. However, we rarely/never have
gimple statements not linked into some list. Additionally, if a
statement is linked into a list, it should never be in another. So,
embedding the next/prev links in the statement is more efficient.

In the future, we could have gimple statements getting their prev/next
links from some base class. This way, every other IL element that we
need to string up in lists can inherit common functionality and
iterators.

> Its unclear to me whether gimple_seq's are intended to have a future, or
> whether their functionality should be rolled right into statements
> themselves.  I believe it may be possible to include gimple-iterator.h in
> gimple-stmt.c to provide the implementation without affecting the
> inheritance layout, although I haven't actually tried that path.

For now, keeping them inside gimple is fine. We can keep the typedef
and move it together with the iterators.

> And finally gimplify.[ch] would contain all the stuff required for the front
> ends to generate gimple code.  This is actually a front end interface.  At
> the moment it isn't obvious since all the current gimple code also uses
> trees and calls the gimplifier frequently. As I push gimple types and decls
> into the back end and remove trees, the backend should simply generate
> gimple directly.  Gimplify should slowly become usable only via tree based
> front ends...  (Thus the dotted line from BE to gimplify.. it should be
> removed eventually)

Perhaps we could also rename gimplify to gimple-gen.[ch] to make it
more descriptive?


Diego.