[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=22141,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77482,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77485

--- Comment #9 from Eric Gallager  ---
(In reply to petschy from comment #2)
> #22141 does not mention a DSE issue, nor a segfault of the compiler, so
> hardly an exact duplicate.

Even if it's not a duplicate, it's still related enough to go under "See Also"

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[petschy at gmail dot com]

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

--- Comment #8 from petschy at gmail dot com ---
I created two other bugs (bug 77482 for the segfault and bug 77485 for the DSE
issue). As I noted in the latter, I'm a bit confused about the store merging,
and what change Kyrill's patch will make, as the version compiled with gcc 7.0
somewhat merges the stores using xmm0, so the problem is not that no merging
occurs, but it occurs inconsistently.

Furthermore, there must be a threshold at the amount of data above which the
codegen should decide that it's more efficient to store the bytes in .rodata
and memcpy to the destination than to store with multiple insns, even if
merged.

This logic kicks in at baz_sized(), but does not in baz(). Interestingly, in
the latter no xmm0 was used, every single byte is movb'd after the memset,
whereas foo() and bar() with smaller data used xmm0, too.

Dump of assembler code for function baz():
   0x00400800 <+0>: sub$0x8,%rsp
   0x00400804 <+4>: mov$0x4e20,%edx
   0x00400809 <+9>: xor%esi,%esi
   0x0040080b <+11>:callq  0x4004f0 
   0x00400810 <+16>:movb   $0x30,(%rax)
   0x00400813 <+19>:movb   $0x20,0x1(%rax)
   0x00400817 <+23>:movb   $0x31,0x2(%rax)
   0x0040081b <+27>:movb   $0x20,0x3(%rax)
   0x0040081f <+31>:movb   $0x32,0x4(%rax)

   0x00422674 <+138868>:movb   $0x32,0x4db3(%rax)
   0x0042267b <+138875>:movb   $0x30,0x4db4(%rax)
   0x00422682 <+138882>:movb   $0x30,0x4db5(%rax)
   0x00422689 <+138889>:add$0x8,%rsp
   0x0042268d <+138893>:retq   

Even if the byte stores were merged into 64bit stores, the function still would
be huge, and a memcpy instead would be way better.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #7 from ktkachov at gcc dot gnu.org ---
I can confirm that for the missed store merging optimisation it is fixed by my
WIP patch that I'm iterating on [1].

The consecutive constant byte stores are merged into 64-bit stores.
On aarch64 the resulting assembly file at -O2 is reduced from 40757 lines to
32965 lines.

[1] https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01512.html

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #6 from Richard Biener  ---
Separate bugs really help.  Leaving this for the missed optimization.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[petschy at gmail dot com]

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

--- Comment #5 from petschy at gmail dot com ---
Sorry. Should I open dedicated bugs for them, or can you work from this single
one? Though the example code would be the same. Probably I would have picked a
more descriptive title mentioning the DSE issue, the bogus error message
formatting and the segfault.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
You have like three different bugs in listed in here so it was hard to
understand which one was which :)

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #3 from Andrew Pinski  ---
.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[petschy at gmail dot com]

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

--- Comment #2 from petschy at gmail dot com ---
#22141 does not mention a DSE issue, nor a segfault of the compiler, so hardly
an exact duplicate.

[Bug c++/77456] Suboptimal code when returning a string generated with a constexpr fn at compile time

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00201.html

*** This bug has been marked as a duplicate of bug 22141 ***