This is the mail archive of the
mailing list for the GCC project.
Re: type consistency of gimple
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: GCC <gcc at gcc dot gnu dot org>, "Mitchell, Mark" <mark at codesourcery dot com>, "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>, "Zadeck, Kenneth" <zadeck at naturalbridge dot com>
- Date: Fri, 11 Aug 2006 17:03:28 -0400
- Subject: Re: type consistency of gimple
- References: <44DCEAAA.firstname.lastname@example.org> <email@example.com> <44DCEDF1.firstname.lastname@example.org> <email@example.com>
Richard Guenther wrote:
> On 8/11/06, Kenneth Zadeck <firstname.lastname@example.org> wrote:
>> Richard Guenther wrote:
>> > On 8/11/06, Kenneth Zadeck <email@example.com> wrote:
>> >> Mark,
>> >> I have had some discussions with Honza and Diego about the type
>> >> consistency at the gimple level. They told me that Andrew was in the
>> >> process of making gimple properly type consistent.
>> >> I just wanted to point out how this effects encoding gimple into
>> >> If the gimple is type consistent, then it looks like the only place
>> >> where I will need to write type references is at CONVERT_EXPRs and
>> >> NOP_EXPRs. If it is not type consistent, Diego and Honza do not
>> >> that I can properly get away without putting type references at every
>> >> tree node.
>> >> This looks like about 20% of the size of writing a function body.
>> I do
>> >> not know how close Pinskia's project is to completion, but
>> anything that
>> >> you, or any one else, could do to help will pay off for LTO. It has
>> >> been suggested that I assume that gimple is type consistent as a
>> way to
>> >> force the issue. I like this idea, but it is not something that I
>> >> should be kept a secret either.
>> > Maybe you can elaborate how you are missing information (assuming
>> > the SSA temporaries still have a type in their "decl" node)?
>> > fold relies on exact matching types for arithmetic operands, the only
>> > place where type transitions are not explicit in all cases is for
>> > MODIFY_EXPRs which can have an implicit type-conversion from
>> > the type of the RHS to the type of the LHS (see
>> > tree_ssa_useless_type_conversion()).
>> > Richard.
>> I actually do not know the details. From what I was told by Diego and
>> Honza while we were in Russian is that what you say is in fact the gold
>> standard, and unfortunately gcc does not live up to that standard. The
>> feeling was that Andrew was in fact fixing bugs, not changing the
>> definition of gimple.
>> I am writing this because no one seems to think that Andrew, and the
>> reviewers are really finished with this process and I was just giving a
>> supportive nudge.
> Ok, maybe it's about time we put the various patches that are floating
> around to verify this type correctness on the LTO branch? I know that
> at least at some point we could bootstrap with them.
It is quite possible that that may be the correct plan. We should wait
until some of the gimple elite respond this email. I know that honza's
patch has rotted because he tried it in russia and it was doa. I assume
that pinskia has a valid one since he has been beating out the varmints.