[Bug target/88027] PowerPC generates slightly weird code for memset

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from acsawdey at gcc dot gnu.org ---
Backport to 8 tested ok and is now checked in as 267580.

[Bug target/88027] PowerPC generates slightly weird code for memset

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-03
   Assignee|unassigned at gcc dot gnu.org  |acsawdey at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from acsawdey at gcc dot gnu.org ---
This is fixed in trunk but I should backport to 8 now too.

[Bug target/88027] PowerPC generates slightly weird code for memset

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
It's fixed now?  Aaron, does this still need backports?  Or can this PR be
closed :-)

[Bug target/88027] PowerPC generates slightly weird code for memset

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
This appears to have to do with alignment. In this test case,
expand_block_clear() sees alignment of only 8 bits for the pointer p. If you
declare a local struct st and pass that to __builtin_memset, it sees alignment
of 128 bits and generates 4 stxv or stvx.

There is a bug here though:

  for (offset = 0; bytes > 0; offset += clear_bytes, bytes -= clear_bytes)
{
  machine_mode mode = BLKmode;
  rtx dest;

  if (TARGET_ALTIVEC
  && ((bytes >= 16 && align >= 128)
  || (bytes >= 32 && TARGET_EFFICIENT_UNALIGNED_VSX)))

The intention here was to only do unaligned VSX if there were at least 32 bytes
to clear. However because bytes is decremented, what this actually does is to
always do the last 16 bytes using std if it is unaligned. This doesn't make a
lot of sense and would be an easy fix.

[Bug target/88027] PowerPC generates slightly weird code for memset

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 CC||acsawdey at gcc dot gnu.org

--- Comment #2 from acsawdey at gcc dot gnu.org ---
What can I say? expand_block_clear() steps through the block to be cleared,
using smaller writes at the end if necessary. The rtx is generated for the
write by:

  dest = adjust_address (orig_dest, mode, offset);

  emit_move_insn (dest, CONST0_RTX (mode));

My guess is scheduling moved the gpr stores up.

[Bug target/88027] PowerPC generates slightly weird code for memset

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 45004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45004=edit
File that shows the problem

I changed the test not to return 0 between showing the test and the code
generated.  This attachment does not return anything which matches the code
generated.

[Bug target/88027] PowerPC generates slightly weird code for memset

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Target||powerpc64-linux-gnu-*,
   ||powerpc64le-linux-gnu-*
 CC||acsawdey at linux dot 
vnet.ibm.com
   ||, dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64-linux-gnu-*,
   ||powerpc64le-linux-gnu-*
  Build||powerpc64-linux-gnu-*,
   ||powerpc64le-linux-gnu-*
   Severity|normal  |enhancement