https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91449
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-08-14
Blocks| |83819
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
Sigh. For some reason, although the powerpc64* back-end merges 8 character
stores into single 64-bit integer stores, and even though it supports int128_t,
it doesn't let 16-byte char stores get merged into int128_t stores. This is
what I was referring to here:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00997.html
With the test case below, the 8 byte store results in:
# _5 = PHI <3544952156018049024(2), 3906085646303834112(3)>
MEM <long unsigned int> [(char * {ref-all})&a] = _5;
while the 16-byte in:
# iftmp.1_2 = PHI <&b8(2), &MEM <const char[32]> [(void *)&a8 + 1B](3)>
__builtin_memcpy (&a, iftmp.1_2, 16);
and the strlen optimization doesn't (yet) handle the memcpy case.
const char a8[32] = "0123456";
const char b8[32] = "6543210";
void f8 (int i)
{
char a[32];
__builtin_memcpy (a, i ? a8 + 1 : b8, 8); //
if (__builtin_strlen (a) < 6)
__builtin_abort ();
}
void f16 (int i)
{
char a[32];
__builtin_memcpy (a, i ? a8 + 1 : b8, 16);
if (__builtin_strlen (a) < 6)
__builtin_abort ();
}
The test guards the 128 byte stores with '#if __SIZEOF_INT128__ == 16' but that
isn't good enough.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations
