This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Finally a main line version that passes LAPACK's test suite ...
- To: law at cygnus dot com
- Subject: Re: Finally a main line version that passes LAPACK's test suite ...
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Fri, 26 Feb 1999 12:24:26 -0800
- CC: craig at jcb-sc dot com, toon at moene dot indiv dot nluug dot nl, egcs at egcs dot cygnus dot com
- References: <24783.920059954@hurl.cygnus.com>
- Reply-to: mark at markmitchell dot com
>>>>> "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