Re: SSA usage question

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    OK, if the values are anything other than constants, then we need to
    go out of our way to express them as IL statements.  

Well they have to be expressed as IL statements, but I don't see why
we have to go out of our way: gimplification should do that in a
straightforward manner.

    I thought these values were actual constants and were the same for
    every object of the same type (like they are in C).

That's one situation.  But there are two situations where the values are not
the same for every object of the type.  One is when you have a discriminated
record in Ada.  In that case, one or more fields are used in the layout of
the record.  For example,

	type r (d: integer; b: boolean) is record
	  f1: array (1..d) of integer;
	  case d is
	    when false =>
	      f2, f3: integer;
            when true =>
	      f4: float;
        end record;

The other case is an unconstrained array.  Pointers to these are a record
with two fields.  One points to the data and the other points to a template
that gives the bounds of the array.

    Having them change inside a type attribute in ways not obvious to the
    optimizers is asking for trouble.

Of course!  Right now the "trouble" is that we ICE because the optimizer
thinks the variable for a TYPE_MIN_VALUE isn't needed and deletes the
definition and the set.

But the issue is that there were two ways of doing this:

(1) Make the optimizers aware of the type fields.
(2) Put the fields into the ARRAY_REF and COMPONENT_REF.

Originally, I was in favor of (1), but that was when I forgot about
PLACEHOLDER_EXPRs, which make that probably impossibly complex, so now
I'm in favor of (2).