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