Re: PR 17884

[Fariborz Jahanian <fjahanian at apple dot com>]

On Oct 12, 2004, at 3:19 PM, Dale Johannesen wrote:

> This changes the doc for 'asm volatile' to reflect my current 
> understanding,
> as described in the PR.  An example that contradicts rth's explanation 
> is
> also removed.  Ran 'make info' and verified the output looked OK.
>
> Index: extend.texi
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
> retrieving revision 1.223
> diff -u -d -b -w -p -r1.223 extend.texi
> --- extend.texi 5 Oct 2004 07:15:01 -0000       1.223
> +++ extend.texi 12 Oct 2004 22:16:57 -0000
> @@ -3724,8 +3724,8 @@ if your instruction does have a side eff
>  appears not to change, the old value of the variable may be reused 
> later
>  if it happens to be found in a register.
>
> -You can prevent an @code{asm} instruction from being deleted, moved
> -significantly, or combined, by writing the keyword @code{volatile} 
> after
> +You can prevent an @code{asm} instruction from being deleted
> +by writing the keyword @code{volatile} after
>  the @code{asm}.  For example:
>
>  @smallexample
> @@ -3737,36 +3737,22 @@ the @code{asm}.  For example:
>  @end smallexample
>
>  @noindent
> -If you write an @code{asm} instruction with no outputs, GCC will know
> -the instruction has side-effects and will not delete the instruction 
> or
> -move it outside of loops.
>
>  The @code{volatile} keyword indicates that the instruction has
>  important side-effects.  GCC will not delete a volatile @code{asm} if
>  it is reachable.  (The instruction can still be deleted if GCC can
>  prove that control-flow will never reach the location of the
> -instruction.)  In addition, GCC will not reschedule instructions
> -across a volatile @code{asm} instruction.  For example:
> -
> -@smallexample
> -*(volatile int *)addr = foo;
> -asm volatile ("eieio" : : );
> -@end smallexample
> -
> -@noindent
> -Assume @code{addr} contains the address of a memory mapped device
> -register.  The PowerPC @code{eieio} instruction (Enforce In-order
> -Execution of I/O) tells the CPU to make sure that the store to that
> -device register happens before it issues any other I/O@.
> -
> -Note that even a volatile @code{asm} instruction can be moved in ways
> -that appear insignificant to the compiler, such as across jump
> -instructions.  You can't expect a sequence of volatile @code{asm}
> -instructions to remain perfectly consecutive.  If you want consecutive
> -output, use a single @code{asm}.  Also, GCC will perform some
> -optimizations across a volatile @code{asm} instruction; GCC does not
> -``forget everything'' when it encounters a volatile @code{asm}
> -instruction the way some other compilers do.
> +instruction.)  Note that even a volatile @code{asm} instruction
> +can be moved relative to other code, including across jump
> +instructions.  For example, you can't use a volatile @code{asm}
			 For example, you can't use floating point instructions to set the
bits of a floating point control register and expect those instructions
not be moved...

> +instruction to set the bits of a floating point control register
> +and expect that floating point instructions will not be moved
> +across the @code{asm}; they can be.  Similarly, you can't expect a
> +sequence of volatile @code{asm} instructions to remain perfectly
> +consecutive.  If you want consecutive output, use a single @code{asm}.
> +Also, GCC will perform some optimizations across a volatile @code{asm}
> +instruction; GCC does not ``forget everything'' when it encounters
> +a volatile @code{asm} instruction the way some other compilers do.

Maybe you want to say what you mean by ``forget everything''.
>  An @code{asm} instruction without any operands or clobbers (an ``old

						without any output operands or...
- fariborz

>  style'' @code{asm}) will be treated identically to a volatile