Re: RFC: gimple.[ch] break apart

[Andrew MacLeod <amacleod at redhat dot com>]

On 11/01/2013 10:45 AM, Diego Novillo wrote:
> 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?
There are no classes. It's an include dependency relationship of the 
files I'm trying to split out....  Ie who includes/has visibility to a 
file/component.
> 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?
Isnt "gimplify" clear to everyone? :-)  I've even been referring to an 
interface to the backend target info for the front end as "targetify" 
lately :-)

I don't care much about the specific name, so whatever is agreed.

Andrew