Simplifying Gimple Generation

[Michael Matz]

Hi,

On Thu, 15 Nov 2012, Lawrence Crowl wrote:

> They allow us to use the same name for the same actions in two
> different contexts.  In particular, distinguishing between statement
> construction in SSA and non-SSA.

I don't see the difference, and I don't see where you need context data to 
distinguis that, in case you really need to.

> > That is, I'm not yet convinced that you really need any local
> > data for which you'd have to add helper classes.
> 
> We also need to ask if we will ever need local data.  If we plan
> for it now, future changes might be possible without affecting
> existing code.  Otherwise, we might require more substantial patches.

But so it _now_ requires substantial patches without it being clear that 
we ever need the complications.  Please don't optimize prematurely.

> > statements without introduction of any helper class.  Basically, 
> > whenever a helper class merely contains one member of a different 
> > type, then I think that other type should be improved so that the 
> > wrapper class isn't necessary anymore.  Fewer types -> good :)
> 
> While I would agree that unnecessary types are bad, I have found that 
> having types to represent distinct concepts is a good way to structure 
> my thinking and catch my errors.

But where exactly are your concepts different?  We have gimple_seq, we can 
append to it.  You had ssa_seq, you could append to it (nicer).  We can 
construct new statements already (boilerplaty), you can construct new 
statements (nicer).  It just the same with a leaner interface.


Ciao,
Michael.