From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@cygnus.com>
To: Bill Currie <bcurrie@tssc.co.nz>
Cc: Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>, Horst von Brand <vonbrand@inf.utfsm.cl>, Matthias Urlichs <smurf@noris.de>, egcs@cygnus.com
Subject: Re: Incrementing volatiles? 
Date: Wed, 15 Jul 1998 17:22:00 -0000
Message-id: <21583.900542629@hurl.cygnus.com>
References: <35AD22FF.7436@tssc.co.nz>
X-SW-Source: 1998-07/msg00541.html

  In message < 35AD22FF.7436@tssc.co.nz >you write:
  > 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.
They're already used whenever possible.

  > 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)))]
  >   ""
This is better handled by the standard patterns which can check the
arguments, and if they are the same produce a 2 operand add.

In general, if you find yourself proposing new RTX codes, or new
named patterns, then you're probably heading down the wrong path.


jeff