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


    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

	foo.field
      =>
	*((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
      code generation:

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.


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