This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: type consistency of gimple
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Kenneth Zadeck <zadeck at naturalbridge dot com>, Richard Guenther <richard dot guenther at gmail dot com>, GCC <gcc at gcc dot gnu dot org>, "Novillo, Diego" <dnovillo at redhat dot com>, "Hubicha, Jan" <jh at suse dot cz>, "Edelsohn, David" <dje at watson dot ibm dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: Mon, 14 Aug 2006 08:20:10 -0700
- Subject: Re: type consistency of gimple
- References: <44DCEAAA.9000306@naturalbridge.com> <84fc9c000608111344l3cc4b9f0w97f104da6ed5b7ad@mail.gmail.com> <44DCEDF1.9010902@naturalbridge.com> <84fc9c000608111356n6bd522d5gd349007fdcb0cd1b@mail.gmail.com> <44DCF0A0.1060005@naturalbridge.com> <44DF6702.4060901@codesourcery.com> <44E074F4.3050402@dberlin.org>
Daniel Berlin wrote:
> 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 agree with the thrust of your email.
If engineering excellence were our primary goal, and we had a master
engineering plan for GCC, and we all committed to following the master
plan, we'd clearly put something like type-consistent GIMPLE early on
the plan because everyone agrees it is The Right Thing from an
engineering point of view.
However, (a) all of the antecedents in the previous sentence are false,
and (b) we are resource-limited. So, GCC development tends to let the
pressure build on some set of infrastructure until it has been painfully
obvious for some amount of time that it has to change. (In my
experience, the same thing happens in developing proprietary software;
convincing product management to let you spend significant time fixing
something that's not on the next release's feature list requires some
good salesmanship.)
Demonstrating proof-of-concept for functionality is important because it
(a) builds community interest (as you mention by saying how new code
tends to appear immediately after something works), and (b) convinces
people with resources (including companies and individuals that make
non-sponsored contributions to the toolchain) that a particular
technology has good potential RoI.
I think the ultimate question here is the usual: is this the *best* use
of the engineering time we have available? And that value-judgment is
ultimately made by the people funding LTO; I haven't yet had a chance to
talk to our customer about this issue. But, my personal opinion is that
I would rather see LTO working, and not try to solve orthogonal problems
along the way.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713