Re: gimplify_parameters

[Richard Henderson <rth at redhat dot com>]

On Mon, Dec 20, 2004 at 07:13:02PM -0500, Richard Kenner wrote:
> We can't just call gimplify_type_sizes in that context because it can make
> variables in the current function that should be in the parent function (or
> be nowhere, if the type is global, though the latter can occur only in Ada).

So I see that Temp_File_Record is apparently a non-local varible sized
structure.  I see that the Ada front end has done *some* stuff to try
to make this work, like promoting portions of the computation into
global variables.  E.g.  system__file_io__temp_file_record__next___OFFSET.

Not having managed to get a breakpoint set at the right place to watch
things happen, I'm _presuming_ that there is still a SAVE_EXPR or three
buried inside Temp_File_Record somewhere.  I can't see any other way
for D.935 to leak between the two functions.

Now, given that there is a SAVE_EXPR, and that SAVE_EXPR mechanisms
didn't change with gimplify_parameters, I'm not clear on how this was
supposed to be working beforehand.  Namely,

(1) SAVE_EXPRs may be evaluated zero or one times.  Subsequent evaluations
    don't matter because we use previous results.  Thus the only time we
    can evidence a change in behaviour is when previously we had zero
    evaluations and now we have one.

(2) Access to sizeof(parm) or parm.foo where foo is at some varying offset
    implies that these SAVE_EXPRs must be evaluated.  Thus the only way to
    get zero evaluations is not to reference the data at all.

(3) Data exists to be referenced, and thus never referencing data is a
    degenerate case.  Thus in the common case there is at least one
    evaluation of the offsets.

Given all this, I don't see how calling gimplify_type_sizes on the 
parameters on function entry should break things.  The common case
should have evaluated the same expressions, causing the same sort
of side effects on the SAVE_EXPRs.

So what am I missing?  How did things function previously?  Why are
there SAVE_EXPRs inside the sizes of non-local variable sized types
in the first place?


r~