Re: Is clobber "memory" in include/asm-i386/system.h necessary?

Ulrich Windl (
Thu, 2 May 1996 15:15:47 +0200

On 1 May 96 at 19:46, Tom May wrote:

> In include/asm-i386/system.h there are numerous uses of __asm__ which
> clobber "memory". For reference, here they are:
> #define mb() __asm__ __volatile__ ("" : : :"memory")
> #define sti() __asm__ __volatile__ ("sti": : :"memory")
> #define cli() __asm__ __volatile__ ("cli": : :"memory")
> #define save_flags(x) \
> __asm__ __volatile__("pushfl ; popl %0":"=g" (x): /* no input */ :"memory")
> #define restore_flags(x) \
> __asm__ __volatile__("pushl %0 ; popfl": /* no output */ :"g" (x):"memory")
> #define iret() __asm__ __volatile__ ("iret": : :"memory")
> (Uh, iret() is never even used . . .)
> This clobber seems unnecessary since none of these instructions modify
> memory that gcc doesn't know about, and any memory that is modified by
> other means (hardware, interrupt handlers, etc.) is (should be?)

I'm afraid you are seeing it from the wrong perspective: If an
instriction does not modify memory, it does not have side-effects for
gcc. Current data-flow analysis does not handle things like interrupt
flags. If an instruction does not have side-effects it would be a
kind of "nop" and can be moved to a location whatever gcc likes.

push/pop does modify memory, but especially for get/set_flags the
effect is saving/restoring the interrupt flag at the right point.

mb() definitely says "commit all commands up to that point", where
"commit" means "emit the opcodes".

sti/cli should not be allowed to be moved. I hope you'll agree.

> accounted for in other ways such as by using volatile.
> As an experiment, I removed the clobbers, built a kernel, and it ran
> fine (but if you try this at home, you will trigger the gcc common
> subexpression elimination bug, so until it is fixed for real, your
> kernel may or may not work).

Are you sure it's gcc's bug? Maybe you haven't yet hit the bad
sequence of code...

> So what's up with these clobbers? If they aren't necessary, they
> should be removed because they have a detrimental effect on code
> generation. If they are necessary, how about a comment explaining
> why?

I'm sure that other people do understand the asm much better than I,
but I hope my reasoning was correct and helpful to you.

> Tom.