Re: Incrementing volatiles?

[Bill Currie <bcurrie@tssc.co.nz>]

Jeffrey A Law wrote:
> But you can not increment without first reading its value.

However, if the CPU supports `atomic' increments (most if not all CISC
cpus), then it should be used.

> Note, that we are not going to change the meaning of volatile, so debating
> this point probably isn't worth the time.

Hmm, I seem to have been mis-understood.  I was not proposing a change
to the meaning of volatile.  What I was saying is that new RTXs should
be created for the increment and friends orperators.

Ouch I just realised why I was probably misunderstood.  I mean
insn-patterns, not RTXs.  In fact, I don't think new RTXs would be
needed.  Maybe an example would help (i386):

(define_expand "incsi"
  [(set (match_operand:SI 0 "nonimmediate_operand" "")
        (plus:SI (match_dup 0)
                 (match_dup 1)))]
  ""
  "
{
  operands[1] = const1_rtx;
}")

(define_insn ""
  [(set (match_operand:SI 0 "nonimmediate_operand" "rm")
        (plus:SI (match_dup 0)
                 (match_operand:SI 1 "const1_operand" "")))]
  ""
  "* return AS1(inc%L0,%0);")

[NOTE: const1_operand may be bogus, I just picked a name out of the hat]

For cpus that don't support this, "incsi" can expand into the old
sequence.

Now, (AIUI) no matter what optimisation level is used, the increment
instruction will be used thus preserving the meaning of volatile to the
limits of the CPU.  Anyway, it's faster (and smaller) than an explicit
read/modify/write.

Unless I misunderstood some of the previous arguments, this is really a
win-win situations.  Yes, I know, there's still the problem of getting
the compiler to USE `incsi' and the others, but it could be worth it in
the long run (I don't think cpu's with `inc' instructions are going to
disappear anytime soon).

Bill
-- 
Leave others their otherness