This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #10 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> > >   char array[] = "abc";
> > >   return __builtin_strlen (array);
> 
> Well, this actually is optimized.

Oops, I failed my copy-paste, I meant to copy:
  char array[] = {'a', 'b', 'c', '\0'};

> > 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.

The alias machinery thinks that array escapes (and we are flow-insensitive
there). It is thus normal that hallo can write to it. I think array doesn't
escape, but it isn't obvious to me where the aliasing code decides that it
does.

(In reply to Jakub Jelinek from comment #7)
> int baz ()
> {
>   char a[4];
>   a[0] = 'a';
>   a[1] = 'b';
>   a[2] = 'c';
>   a[3] = '\0';
>   return __builtin_strlen (a); 
> }
> still won't be optimized.

And we don't "vectorize" it either (llvm doesn't optimize strlen in this case,
but at least the write to a is a single movl $6513249, 4(%rsp) instead of 4
movb).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]