Re: Incrementing volatiles?

[John Vickers <jvickers at dial dot pipex dot com>]

Andreas Schwab wrote:
> 
> "Matthias Urlichs" <smurf@noris.de> writes:
> 
> |> Hi,
> |>
> |> The following code, using egcs-current -O2 -fomit-frame-pointer
> |>
> |>          unsigned int foo;    afoo() { foo++; }
> |> volatile unsigned int bar;    abar() { bar++; }
[...]
> |> abar:   movl bar,%eax
> |>         incl %eax
> |>         movl %eax,bar
> |>         ret
> |>
> |> But actually, it should be perfectly valid to compile both to code using
> |> "incr". After all, both versions read the variable, do something with it,
> |> and then write it out.
> |>
> |> Is there a way to convince the optimizer to do this?
> 
> No.  volatile prevents all attempts to combine instructions, because any
> two references to a volatile variable never match.  This is how gcc
> implements the implementation defined aspects of volatile.

But this is a reason for changing the compiler.

To me, it seems that combining the references into a single instruction
would only be likely to lead to unexpected behaviour if the cpu did
something like:
	read low 16-bits of bar
	write low 16 bits of bar
	read high 16-bits of bar
	write high 16 bits of bar

On machines with insns for m <op>= ri, combining (not necessarily in
"combine")
the volatile memrefs gives very much denser code.  This can make a big
difference in some device drivers.

I don't know the history of this (someone please tell me!) - I
understand that once upon a time gcc did allow volatile memrefs outside
moves, and that when
this changed, it broke a whole load of code which assumed that
certain operations were going to be uninterruptible.  The people
who wrote that code shouldn't have been too suprised when their code
broke.
I guess a decision was made that it was easier to restrict the rtl which
could be generated for volatiles than to fix all the insns in all the
targets to make sure that they handled volatiles in a predictable and
unsuprising way.

It's probably not a great solution, but having a working dead_or_set_p()
after reload would let this be done with peepholes, and also allow some
complex insns to generate better code.  Once upon a time the doc said
that using dead_or_set_p() after reload
was A Good Thing.  The doc wasn't quite right, because the reg notes
weren't reliable.
Maybe they could be made reliable.


John.

(If I don't reply to any further correspondence on this, it's because
I'm on
holiday!)