This is the mail archive of the
mailing list for the GCC project.
Re: SSA usage question
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 6 Jun 04 17:40:18 EDT
- Subject: Re: SSA usage question
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.
Most certainly these values are used! For example, if you have
an array of a type that's a variable size, you have to multiply the index
by that variable size as part of the indexing operation in a ARRAY_REF.
(2) We've failed to gimplify something. In gimple, there are *no*
hidden references to variables.
Then I'd say that GIMPLE isn't powerful enough.
I notice, for instance, that we don't at present properly handle
fields with variable DECL_FIELD_OFFSET. This must be implemented as
*((typeof field *)&foo + unshare_expr(DECL_FIELD_OFFSET(foo)))
which of course must itself be further gimplified.
Yikes! This loses lots of aliasing and alignment information.
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
OK, I suppose that one is possible.
But what about TYPE_SIZE_UNIT being variable for an array?
We can't simply go down to address computations that early: we lose
most of the optimizations that tree-ssa was supposed to by us.
Can you explain again exactly what the problem is in viewing these operations
as having the position and size variables as parameters? It seems like the
most straightforward solution and keeps the tree at the proper level.
This is why I said that get_inner_reference is the key point: it's the
function that knows about all these things.
I must say that I'm quite surprised that none of these issues were
addressed before the merge: these are quite fundamental. We've always
supported variables in sizes and positions and it's a fundamental part
of the type system.