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.
