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: toon at moene dot indiv dot nluug dot nl
- Subject: Re: Finally a main line version that passes LAPACK's test suite ...
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Sun, 28 Feb 1999 09:08:41 -0800
- CC: egcs at egcs dot cygnus dot com
- References: <36D9215B.E17961A0@moene.indiv.nluug.nl>
- Reply-to: mark at markmitchell dot com
>>>>> "Toon" == Toon Moene <toon@moene.indiv.nluug.nl> writes:
Toon> Unfortunately, I still do not understand this. I thought
Toon> that your alias-setting of stack slots was meant to prevent
Toon> overwriting a stack slot still in use (because of aliasing
Toon> between temporary variables) ?
Right. The problem is that if we don't know what alias set to use for
a stack-slot, we must assume that we cannot reuse it. Consider, in C,
something like:
struct S {
int i;
};
struct T {
long l;
};
void f() {
{
struct S s;
}
{
struct T t;
}
}
It is not presently safe to resuse the slot for `s' for `t' since the
rest of the compiler will then assume that `s' does not alias `t'.
This is unsafe even if the compiler assigns alias set zero to both `s'
and `t', because other uses of the stack slot may assign alias sets to
invidual pieces of `s' or `t'; for example adding in:
int* g(struct S* sp) { return &sp->i; }
and then modifying the first block of `f' to look like:
{
struct S s
*g(&s) = 3;
}
would give a piece of the stack slot the alias set for `int'.
Toon> *We* certainly do not have close to 2 million temporary
Toon> single precision variables ! The whole model state is just
Toon> 5 variables x 110 x 100 x 31 x 4 bytes ~ 7 Mbyte ...
Isn't that exactly the blowup you're seeing?
Toon> If the compiler can't see that two items might overlap, they
Toon> shouldn't (or else ....) Types do not play a role in the
Toon> aliasing rules.
There are two things you can do then:
o Give every separate variable a different alias set. This will
tell the compiler that none of them overlap, which could improve
code-generation. This will not reduce stack usage until we
fix the compiler to somehow know how to reallocate stack-slots and
not screw up alias analysis in the process. This is a hard
problem; I'm still thinking about it.
o Turn off -fstrict-aliasing for Fortran.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com