This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/71625] missing strlen optimization on different array initialization style
- From: "glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 25 Jun 2016 08:53:40 +0000
- Subject: [Bug middle-end/71625] missing strlen optimization on different array initialization style
- Auto-submitted: auto-generated
- References: <bug-71625-4 at http dot gcc dot gnu dot org/bugzilla/>
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).