This is the mail archive of the
mailing list for the GCC project.
Re: basic asm and memory clobbers
- From: Richard Henderson <rth at redhat dot com>
- To: David Wohlferd <dw at LimeGreenSocks dot com>, Andrew Haley <aph at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, rth at gcc dot gnu dot org, pinskia at gcc dot gnu dot org, Sandra Loosemore <sandra at codesourcery dot com>
- Date: Fri, 20 Nov 2015 14:05:01 +0100
- Subject: Re: basic asm and memory clobbers
- Authentication-results: sourceware.org; auth=none
- References: <563FE459 dot 3000003 at LimeGreenSocks dot com> <20151109093229 dot GA5260 at gate dot crashing dot org> <56493010 dot 9070707 at LimeGreenSocks dot com> <564A4AA5 dot 1080706 at redhat dot com> <564AC155 dot 4040601 at LimeGreenSocks dot com> <564B9CB1 dot 1060001 at redhat dot com> <564E762B dot 6070705 at LimeGreenSocks dot com> <564EF338 dot 4030703 at redhat dot com> <564EF7FF dot 1070107 at LimeGreenSocks dot com> <564F008B dot 8040703 at redhat dot com> <564F1436 dot 2060005 at LimeGreenSocks dot com>
On 11/20/2015 01:38 PM, David Wohlferd wrote:
On 11/20/2015 3:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory" is not sufficient:
#define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
"r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
Hmm. I would not be at all surprised to see this cause reload
failures. You certainly shouldn't clobber the frame pointer on
any machine which needs one.
If I don't clobber ebp, gcc just uses it:
movl $1000, %ebp
subl $1, %ebp
I believe you'd have to have magic in there to conditionally clobber the
register if it isn't being used as a frame pointer.
The original purpose of this code was to attempt to show that this kind of
"clobbering everything" behavior (the proposed new behavior for basic asm)
could have non-trivial impact on existing routines. While I've been told that
changing the existing "clobber nothing" approach to this kind of "clobber
everything" is "less intrusive than you might think," I'm struggling to believe
it. It seems to me that one asm("nop") thrown into a driver routine to fix a
timing problem could end up making a real mess.
But actually we're kind of past that. When Jeff, Segher, (other) Andrew and
Richard all say "this is how it's going to work," it's time for me to set aside
my reservations and move on.
So now I'm just trying my best to make sure that if it *is* an issue, people
have a viable solution readily available. And to make sure it's all correctly
doc'ed (which is what started this whole mess).
I'd be perfectly happy to deprecate and later completely remove basic asm
Because IMO it's essentially useless. It has no inputs, no outputs, and no way
to tell the compiler what machine state has been changed. We can say that "it
clobbers everything", but that's not actually useful, and quite difficult as
you're finding out.
It seems to me that it would be better to remove the feature, forcing what must
be an extremely small number of users to audit and update to extended asm.