How to express the fact that arguments don't escape?

[Richard Guenther]

2009/8/16 Richard Guenther <richard.guenther@gmail.com>:
> 2009/8/15 Tobias Schlüter <tobias.schlueter@physik.uni-muenchen.de>:
>> Thomas Koenig wrote:
>>>
>>> On Sat, 2009-08-15 at 18:27 +0200, Tobias Schlüter wrote:
>>>>
>>>> I'm a bit worried that this could pessimize code with very short
>>>> functions but lots of arguments, i.e. when the copying time becomes
>>>> comparable to the runtime.
>>>
>>> I don't think this will be a problem.  SSA tends to generated quite a
>>> lot of intermediate variables anyway (just look at a typical dump for
>>> -fdump-tree-optimized), and all the unnecessary stores will be optimized
>>> away in the generated assembly.  We shouldn't do this if we aren't
>>> optimizing, though.
>>>
>>> Richard, do you concur?
>>
>> Well, the stores and copies are meaningful in this case:
>>  I_2 = I
>>  g(I_2)
>>  I = I_2
>> The stores can't be optimized away.  This means one additional load (I_2 =
>> I) in the best case, and one more additional load and store (get I from
>> memory, store in I_2; get I_2 from memory, store in I) in the worst case.
>
> Correct.  The only difference in that case is that I doesn't escape.  The
> store will be optimized away in case g is inlined though.

And this effect will only be positive on optimizations if you have like

  do i=1,10
     g(i)
     ... = function of i
     f(k)
     ... = function of i
   end do

where the load from i can be CSEd around the call to f (because it didn't
escape to g).  So I expect this to be a pretty rare case.  Note it doesn't help
loop optimizations as i is still clobbered in unpredictable ways by g.

The copying would generally help for the intent-in case though, as loop
optimizers do not need to consider the induction variable clobbered.
Thus, for intent-in parameters do
   tmp = i;
   g (&tmp);
instead of
   g (&i);

Richard.

>> In other words, I'll have to try with some benchmarks.
>
> Richard.
>