Missed optimisation case - internal use of STCin

[Iain Buclaw via Digitalmars-d]

Hi,

I'm currently testing out a GCC optimisation that allows you to 
set call argument flags.  The current assumptions being:

in parameters  =>  Assume no escape, no clobber (read-only).
ref parameters, classes and pointers  =>  Assume worst case.
default  =>  Assume no escape.


See here for implementation details:
http://gcc.gnu.org/ml/fortran/2010-05/msg00032.html


The idea for the 'in' parameters being that if we have the 
following:
--
bool somefunc (in char[] a);


The compiler can assume that whatever parameters are passed, they 
do not changes.  So the compiler can more aggressively optimise 
the following case, for instance.

eg:
--
char[] foo = "bar";
assert(foo == "bar");
somefunc(foo);
assert(foo == "bar");


One problem I've found with this though, is that the front-end 
tends to set all library function parameters as STCin, so the 
optimisation is fundamentally broken:

eg:
--
int[3] arr = [2,3,1];
arr.sort;  // Defined internally as _adSort(in void[], in 
TypeInfo);
assert(arr[0] == 1);  // Compiler infers as false, throws assert.


I think it would be more than reasonable to fix the frontend here 
so that the internal representation better matches that found in 
the internal runtime library.  Just wanted to pass this by you 
guys first.


Regards
Iain.