This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
Mark,
You wrote:
> 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?
Yeah, but the point I try to get across is that we're not reusing stack
space (temporary arrays) *within* SUBROUTINEs. g77 is not able to
generate array temporaries, and it won't generate scalar temporaries
that alias stack slots assigned to arrays. It also doesn't generate
pointers to "sections" of arrays - this is all Fortran 90 stuff that g77
doesn't do yet. So I'm still lost as to how your change can bring this
about.
To put an end to this speculation, our code looks like:
PROGRAM HIRLAM
DO I = 1, NSTEP
CALL DYN ! Newtons second law, etc.
CALL RADIA ! Radiative transfer
CALL CONVEC ! Convective processes
CALL CONDENS ! Large scale condensation
CALL SURF ! (momentum, heat) fluxes at surface
CALL VDIFF ! Vertical (turbulent) exchange of energy
ENDDO
END
Each of these subroutines has a several megabytes of local (stack based)
storage. So at the end of DYN, several megabytes of stack get "freed",
and subsequently RADIA "allocates" several megabytes of stack, which -
given a reasonable underlying OS, would mean: The same megabytes.
AFAICS, your alias sets do not do anything across function boundaries
(i.e. they work for a function at a time). Note that inlining doesn't
play a role here.
So why does -fno-strict-aliasing have any effect ?
Cheers,
--
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com