[Bug middle-end/71625] missing strlen optimization on different array initialization style

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #1)
> (In reply to Renlin Li from comment #0)
> >   char array[] = "abc";
> >   return __builtin_strlen (array);
> 
> There are DUPs for this part.

Well, this actually is optimized.

GCC is able to fold strlen of a string literal very early, but the rest is done
in the strlen pass.  For foo, there is:
  array = "abc";
  _1 = __builtin_strlen (&array);
where we can easily compute the string length of the rhs and copy it over to
the lhs (array).
In bar, we have instead:
  array[0] = 97;
  array[1] = 98;
  array[2] = 99;
  array[3] = 0;
  _1 = __builtin_strlen (&array);
and right now, the strlen pass only handles the various string/memory builtins
plus stores of zero.  For this to work, we'd need to also instrument scalar
stores of non-zero values, and record some transitive string length > N rather
than string length equals to N, so for the array[0] = 97; store we'd record
string length at &array[0] is > 0, for array[1] = 98; update that record to say
> 1, then > 2.

> Here it depends if we produce:
> 
> size_t tmp1=hallo();
> size_t tmp2=strlen(array);
> return tmp1+tmp2;
> 
> or use the reverse order for tmp1 and tmp2. Currently we evaluate a before b
> in a+b, this example seems to suggest that when one sub-expression is pure
> and not the other, it would make sense to evaluate the pure one first
> (assuming we can determine that information early enough). It also depends
> where the C++ proposal about order of evaluation is going...
> 
> Or we could do like clang and improve alias analysis. We should know that
> array doesn't escape and thus that hallo() cannot write to it.

The strlen pass uses the alias oracle, so the question is why it thinks the
call might affect the array.