On Wed, Oct 30, 2013 at 10:26 PM, Andrew MacLeod <amacl...@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.
