This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: type consistency of gimple


Mark Mitchell wrote:
> Kenneth Zadeck wrote:
> 
> So, I guess my inclination would be to just write out the type
> information now, and thereby avoid the dependency on fixing GIMPLE.
> 

Please don't take this the wrong way, but this approach is the reason
GIMPLE is not flat/tupelized, not type consistent *right now*, and why
this discussing is even occurring at all.

I do not *fault* Diego (and others) for the decision to get a prototype
of GIMPLE/tree-ssa first, and clean it up later.  As a matter of fact, I
would have done the same thing and made the same choices.  But we should
be aware that most of the time, the hard cleanup never comes because:

1. you quickly gain critical mass of others contributing passes right
after the prototype is written (this is what happened with
GIMPLE/tree-ssa, even though the thing was changing out from under us,
and in fact, a lot of the passes that depended on it don't even exist
today, like goto-elimination :P)

2. By the time you are done enough with the prototype that you feel
comfortable going back to fix it, the number of things depending on the
way the prototype does things has raised the engineering effort to
revisit the decisions from person months to person years.

3. It's very hard to do it incrementally, because anything can generate
trees that violate the invariants.  The only real incremental approach
is to pick a point in the compiler, and ensure that everything up to
that point generates okay trees, and verify at that point.  Then you
keep moving the point forward.

There are other reasons, of course, such as resource and people
management, but hard incrementalness generally means no "spare-time
contributors" will attack it.

I'm not saying your approach isn't the way to go, I'm just saying that
we should be aware that rarely have we actually been able to revisit the
the changes we want to revisit later on, when it has come to serious
infrastructure.

If this is a cleanup we actually want done, IMHO, we should do it first.

--Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]