This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Incrementing volatiles?
- To: Bill Currie <bcurrie at tssc dot co dot nz>
- Subject: Re: Incrementing volatiles?
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 15 Jul 1998 16:43:49 -0600
- cc: Andreas Schwab <schwab at issan dot informatik dot uni-dortmund dot de>, Horst von Brand <vonbrand at inf dot utfsm dot cl>, Matthias Urlichs <smurf at noris dot de>, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
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