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]

Re: Finally a main line version that passes LAPACK's test suite ...


>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

    Jeffrey> Another thought -- for arrays on the stack, maybe we
    Jeffrey> could set the alias set based on the underlying type
    Jeffrey> instead of the array itself.  That way arrays with
    Jeffrey> different lifetimes, but the same underlying type could
    Jeffrey> share stack slots.

I bet, although I have not yet confirmed this, that we are already
set up to do this in C:

  else if (TREE_CODE (type) == ARRAY_TYPE)
    /* Anything that can alias one of the array elements can alias
       the entire array as well.  */
    TYPE_ALIAS_SET (type) = c_get_alias_set (TREE_TYPE (type));

But, you're right; we won't currently combine or split a stack slot that
is an an array to fit a new request, so only two arrays of the same
size will get overlaid.  You're right that it would be safe to do
this.

One thing I plan to do RSN is enhance c_get_alias_set to DTRT
w.r.t. structs/unions.  We have the subset machinery already, and now
that alias sets seem to be working in a pretty stable fashion, I think
this is the right time to try this.  That will (as a side-effect)
allow us to reuse stack-slots when they are allocated to structure
types.  (Right now, we can't because all structures have alias set
zero.)  This will probably make a reasonable improvement on the bloat
induced by my change for C/C++, but, of course will not affect
Fortran.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com


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