This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question on gimplify.c:create_tmp_var
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 6 Jun 04 14:03:48 EDT
- Subject: Re: Question on gimplify.c:create_tmp_var
Why are you using VIEW_CONVERT_EXPR on something other than scalars?
Let me give you a typical example. Suppose I have the following types
and data object in Ada:
type r1 (d : boolean := false) is record
case d is
when false =>
f1: integer;
when true =>
f2: integer;
f3: integer;
end case;
end record;
type r2 is record
f4: integer;
f5: r1;
end record;
x : r2;
The type of f5 isn't really r1, but is an special subtype of r1 which has a
fixed size (the maximum size). But if I say x.f5, that *does* have the type
"r1", not the special type (this is Ada semantics). So there's a
VIEW_CONVERT_EXPR going on.
Now suppose I have x.f5.f1 as either an LHS or an RHS. The ".f1" is an
operation whose input type is r1. So this looks like a COMPONENT_REF of a
VIEW_CONVERT_EXPR of a COMPONENT_REF. But, ignoring the discriminant check,
this is actually a single load (and might even be a part of a register since
r2 could live in registers on a 64-bit machine).
So when processing the two COMPONENT_REFs, you have to ignore the
VIEW_CONVERT_EXPR that's in there because all it's there for is to preserve
type correctness.
Now, yes, it is possible to do the ".f1" operation on the special subtype
that f5 is. But that's not exactly equivalent to Ada semantics and is also
tricky, so it seems pointless. All the code in the pre-tree-ssa compiler
handled this nesting correctly and it seems it's only the small change I sent
you to do so for tree-ssa as well.