RFA: Revamp fortran array types
Toon Moene
toon@moene.org
Wed Aug 19 13:01:00 GMT 2009
Michael Matz wrote:
> On Tue, 18 Aug 2009, Toon Moene wrote:
>
>> BTW, does everyone realize that - as soon as link time optimizations are
>> the default - we can throw out all these nonsense, as it is then
>> perfectly (though perhaps costly) determinable whether two names point
>> to the same memory location(s) ?
>
> Nope, not really. Generally it's not even possible for a single procedure
> program. You are right that we get more precise points to info but you
> still can't rule out pointers pointing to some unknown global memory (e.g.
> in shared libs), not for all of them at least. So type based
> disambiguation will still be useful.
Well, I certainly shouldn't have used the adverb "perfectly".
However, perhaps more important is that my bias towards large Fortran
programs is showing.
In general, the programs I work with have 10s to 100s of MBs of *text*,
i.e., instructions. Because they almost invariably claim the whole
machine for a single instance, there's little use for shared libraries.
So, once -flto is working satisfactorily, I'm planning to build the
Fortran run-time library and private versions of glibc and libm with
-flto and link the whole shebang statically.
Under those circumstances, there will be only few pointers who "escape"
the complete alias analysis. It is probably safe to say that just
ignoring them in the analysis (assume that they point to "everything")
doesn't impact the final outcome that much.
--
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html
More information about the Gcc-patches
mailing list