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: 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.


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