basic asm and memory clobbers

David Wohlferd dw@LimeGreenSocks.com
Fri Nov 20 12:38:00 GMT 2015


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
.L2:
         #
         subl    $1, %ebp
         jne     .L2

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).

dw



More information about the Gcc mailing list