RFA: Revamp fortran array types

[Richard Guenther]

On Wed, Aug 19, 2009 at 2:47 PM, Toon Moene<toon@moene.org> wrote:
> 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.

Note however that we currently do not do interprocedural alias analysis
at all.  Note also that for large programs whole-program pointer analysis
can be quite time and memory consuming ;)

Richard.