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