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


David Edelsohn wrote:
>>>>>> Diego Novillo writes:
>>>>>>             
>
> Diego> Agreed.  This is a good opportunity for us to design a GIMPLE type
> Diego> system.  Besides the obvious space savings and cleanliness, it is also
> Diego> needed to remove lang_hooks.types_compatible_p.
>
> 	And this last statement is the key point.  We can and probably
> should implement a prototype LTO without cleaning up the type system, but
> for LTO to be usable in a production compiler, the GIMPLE type system will
> need to be fixed.  Cleaning the type system is not an immediate
> requirement -- not a dependency for the initial implementation of LTO --
> but LTO cannot be generally usable without this problem being addressed.
> A more compact representation is a byproduct, but multi-language
> correctness is necessary for full, production functionality.
>
> David
>
>   
I am modifying my code so that their is a preprocessor flag,
STUPID_TYPE_SYSTEM that either writes or does not write the redundant
type nodes. 

The comments by Diego imply that not only is this a space issue but that
will have to be solved in order to get rid of one or more of the
lang_hooks.  Thus, it does make some sense to work on this sooner rather
than later. 

I would suggest that we ask those with patches to strengthen the type
system to contribute those patches to the lto branch and for diego (who
I believe has the last working type checker) to contribute that type
checker to the lto branch.  And that we further invite those in the
community who are willing to attack some of these problems to contribute
those patches to the lto branch as they become available, on the basis
that perhaps we can provide some fast path to getting them in the
mainline if we are able to solve this problem in a timely manner. 

When we get to the point where can compile C with the type checker, we
should turn it on in the lto branch and remove my STUPID_TYPE_SYSTEM
code.  This will keep the pressure up but at the same time allow us to
get a prototype in a timely manner. 

Kenny


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