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: SSA usage question


On Sun, Jun 06, 2004 at 02:56:11PM -0400, Richard Kenner wrote:
> Suppose I have a INTEGER_TYPE with a TYPE_MAX_VALUE that's an expression
> (originally a SAVE_EXPR).  That can be gimplified in the routine that
> handles decls so then it's a VAR_DECL.
> 
> But whose job is it to mark the variable used?  I see only five places
> where set_is_used is called, three in tree-outof-ssa.c and two in
> tree-ssa-live.c.
> 
> None of them make any attempt to mark the variables in variable-sized or
> positioned types as being used.
> 
> It needs to mark TYPE_SIZE, TYPE_SIZE_UNIT, DECL_FIELD_OFFSET, TYPE_MIN_VALUE,
> TYPE_MAX_VALUE, and perhaps some others.
> 
> Where is this supposed to be done?

You have a fundamental misconception here.  One of the following is true:

  (1) These variables are *not* used.  They're present in the original
      type system, but don't actually affect the generated code in any way.

      I would suspect that this would be true, for instance, of any
      dynamically sized array until and unless you decided to emit
      bounds checks for the array.

  (2) We've failed to gimplify something.  In gimple, there are *no*
      hidden references to variables.

      C.f. gimplify_modify_expr, which emits a structure copy of a
      dynamicaly sized type as a call to __builtin_memcpy.  Which has
      the effect of exposing TYPE_SIZE_UNIT as a variable that's used.

      I notice, for instance, that we don't at present properly handle 
      fields with variable DECL_FIELD_OFFSET.  This must be implemented as

	foo.field
      =>
	*((typeof field *)&foo + unshare_expr(DECL_FIELD_OFFSET(foo)))

      which of course must itself be further gimplified.

      Similarly for ARRAY_REF with a variable TYPE_MIN_VALUE in the domain.
      There we have several possibilities.  First, just drop down to
      pointer arithmetic immediately:

	foo[i]
      =>
	*((typeof foo[0] *)&foo + (i - min) * sizeof(foo[0]))

      Second, redefine the meaning of
      gimplified arrays such that variable TYPE_MIN_VALUE is no longer 
      considered after gimplification, i.e. is considered zero wrt further
      code generation:

	foo[i]
      =>
	foo[i-min]

      The second choice requires more modifications to other parts of
      the compiler.  The ultimate choice should likely involve LNO folk.



r~


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