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 ...


>>>>> "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


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