This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SSA usage question
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 6 Jun 2004 14:09:28 -0700
- Subject: Re: SSA usage question
- References: <10406061856.AA01243@vlsi1.ultra.nyu.edu>
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~