This is the mail archive of the
mailing list for the GCC project.
Re: type consistency of gimple
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Kenneth Zadeck" <zadeck at naturalbridge 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>
- Date: Fri, 11 Aug 2006 22:56:30 +0200
- Subject: Re: type consistency of gimple
- References: <44DCEAAA.email@example.com> <firstname.lastname@example.org> <44DCEDF1.email@example.com>
On 8/11/06, Kenneth Zadeck <firstname.lastname@example.org> wrote:
Richard Guenther wrote:
> On 8/11/06, Kenneth Zadeck <email@example.com> wrote:
>> 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 dwarf.
>> 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 believe
>> 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 feel
>> 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)? Especially
> 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
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
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.