[Bug inline-asm/63900] New: memory constrains needlessly doing memory clobber

[Bug inline-asm/63900] New: memory constrains needlessly doing memory clobber

[gccbugzilla at limegreensocks dot com]

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

            Bug ID: 63900
           Summary: memory constrains needlessly doing memory clobber
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gccbugzilla at limegreensocks dot com

Using a constraint like this:

   "=m" ( *(struct { char __x[BUFSIZE]; } *)b)

only works for very specific sizes of BUFSIZE (1, 2, 4, 8, 16).  All other
sizes (3, 12, 1000, etc) cause gcc to (silently) fall back to doing a full
memory clobber.

---------------------
#include <stdio.h>

#define MYSIZE 8

inline void 
__stosb(unsigned char *Dest, unsigned char Data, size_t Count)
{
   struct _reallybigstruct { char x[MYSIZE]; } 
      *p = (struct _reallybigstruct *)Dest;

   __asm__ __volatile__ ("rep stosb"
      : "+D" (Dest), "+c" (Count), "=m" (*p)
      : [Data] "a" (Data)
      //: "memory"
   );
}

int main()
{
   unsigned char buff[100], buff2[100];

   buff[5] = 'A';
   buff2[5] = 'M';
   asm("#" : : "r" (buff2));

   __stosb(buff, 'B', sizeof(buff));
   printf("%c %c\n", buff[5], buff2[5]);
}
---------------------

Compile this (4.9.0 x86_64-win32-seh-rev2, using -m64 -O2) with MYSIZE 8 and
look at the -S output.  If this is NOT doing a full clobber, gcc should be able
to just print buff2[5] by moving 77 into r8d before calling printf (which it
does).

Change MYSIZE to 3 (or 12, 1000, 0xfffffff, etc) we see the value getting read
from memory before calling printf, indicating the asm performed a full clobber
(affecting buff2) instead of just clobbering buff as was intended.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David from comment #0)
> Change MYSIZE to 3 (or 12, 1000, 0xfffffff, etc) we see the value getting
> read from memory before calling printf, indicating the asm performed a full
> clobber (affecting buff2) instead of just clobbering buff as was intended.

So that is just an optimization anyways.  So closing as invalid.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[aph at redhat dot com]

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

Andrew Haley <aph at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aph at redhat dot com

--- Comment #2 from Andrew Haley <aph at redhat dot com> ---
(In reply to Andrew Pinski from comment #1)
> (In reply to David from comment #0)
> > Change MYSIZE to 3 (or 12, 1000, 0xfffffff, etc) we see the value getting
> > read from memory before calling printf, indicating the asm performed a full
> > clobber (affecting buff2) instead of just clobbering buff as was intended.
> 
> So that is just an optimization anyways.  So closing as invalid.

Why is this invalid?  Looks like a missed-optimization to me.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
   Last reconfirmed|                            |2014-11-16
                 CC|                            |segher at gcc dot gnu.org
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Reopened; this is a perfectly valid missed optimisation.

Nothing here does a "full memory clobber"; instead, CSE simply doesn't
know how to handle a three-byte datum.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #3)
> Reopened; this is a perfectly valid missed optimisation.
> 
> Nothing here does a "full memory clobber"; instead, CSE simply doesn't
> know how to handle a three-byte datum.

That is because it is BLKmode.  This is most likely going to be a won't fix
really because it is too hard to implement for small benefit.

Also in this case using memset would be better and optimize easier.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[gccbugzilla at limegreensocks dot com]

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

--- Comment #5 from David <gccbugzilla at limegreensocks dot com> ---
I agree that the benefit for 3 bytes isn't going to be a big win.  And
certainly this sample, created from scratch solely to illustrate the problem,
can be better written.  

For a more real-world sample, how about something like this:

   "=m" ( *(struct { char __x[0xfffffff]; } *)__dest)

This code is from glib's __strcpy_g() (I believe the linux kernel also uses
this technique).  The intent here appears to be to tell gcc "flush all of
__dest, even though I don't actually know how big it is."  If only very
specific sizes can be used in memory constraints, rather than avoiding the
memory clobber, they are actually still causing one, just implicitly.

And worse, it is entirely possible that the compiler doesn't have *any* of
__dest in registers.  In that case, performing a "memory" clobber (either
explicitly or implicitly) can be a big expense, that has zero gain.  But of
course there's no way the asm can know that.

I should probably also point out that using memory constraints to avoid a
clobber isn't something I just made up.  It has been in the docs since at least
3.3.6.

The "memory" clobber is an essential tool in a number of cases, but it is a
blunt one.  Being able to inform gcc exactly what you need flushed can't help
but result in better code.  The fact that it does work (albeit in highly
limited circumstances) is what makes me hope it can work more generally.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hp at gcc dot gnu.org

--- Comment #6 from Hans-Peter Nilsson <hp at gcc dot gnu.org> ---
(FWIW, I think Andrew is missing the discussion on gcc@ regarding fixing this
so that it is true to the documentation, as being preferable by e.g. Richi to
removing it from the documentation.)