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:44:15 +0200
- Subject: Re: type consistency of gimple
- References: <44DCEAAA.firstname.lastname@example.org>
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
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