Memory partitioning considered harmful (!?)

[Richard Guenther]

On Thu, 8 Feb 2007, François-Xavier Coudert wrote:

> > One reason this patch increases compile time and memory usage for
> > fortran testcases is the passing-by-reference done on function calls
> > and the habit of fortran programmers to do a lot of I/O in main routines.
> >
> > Some flow-sensitive call clobber analysis, extra support for marking
> > function arguments as not escaping or clobbered and possibly better
> > lowering of fortran I/O intrinsics may fix a big part of this problem.
> 
> I have two questions about that:
>  - how much increase in compile time and memory usage do you see? are
> we talking 2%, 5%, 10%?

On fatigue compile time went from 9s to 14s (on a checking enabled
-O0 -fno-inline build).  I guess that's an upper bound then.

>  - about the second paragraph quoted, would you mind expanding a bit
> on what exactly would be needed? and eventually open a
> missed-optimization PR (and add me to CC)

One thing is that we are not re-using a dt_parm declaration but creating
new ones again and again (and we happen to create SFTs for them).  But
we still coalesce them to one partition with the proposed patch.  (I also
remember darkly proposing a patch for this but getting shot down because
of some thread/reentrancy concerns)

The other thing is to use by-value argument passing conventions for
internal intrinsics wherever possible so that a

  write (*,*) a

does not make 'a' addressable.  This is what makes fatigue so sensitive
to the partitioning choices - we have an addressable induction variable
and miss loop invariant motion of sin() and cos() calls if the memory
tag for the induction variable is coalesced with the wrong things.  The
induction variable only has a memory tag because it is marked addressable
and this is only due to the fact that fatigue re-uses it in an I/O 
statement (like the one quoted above) later in the function.

Richard.

-- 
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs