[Patch] MIPS: Add atomic memory operations for QI and HI modes.

Richard Sandiford rsandifo@nildram.co.uk
Thu Apr 24 21:30:00 GMT 2008


David Daney <ddaney@avtrex.com> writes:
> Richard Sandiford wrote:
>> Hi David,
>> 
>> David Daney <ddaney@avtrex.com> writes:
>>> David Daney wrote:
>>>> This patch adds support for QI and HI mode atomic memory operations to
>>>> MIPS.  This is a minimal implementation of the QI and HI mode operations
>>>> as it only implements sync_compare_and_swap for those modes.  A possible
>>>> future enhancement would be to implement the full set of atomic insns
>>>> for QI and HI modes, but this should be enough to get libstdc++ building
>>>> again.
>>>>
>>>> The patch borrows from the sparc implementation.
>>>>
>>>> Currently testing on mipsel-linux with all languages,
>>>>
>>>> OK to commit if it tests good?
>>> And it did:
>>>
>>> http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01887.html
>>>
>>> This gets us back to clean C++ and libstdc++ test results (except for 
>>> pr31863.C, which times out occasionally when the system is heavily loaded).
>> 
> .
> .
> .
>> 
>> Finally, I thought it would be worth having a version of mips_emit_binary
>> that creates a new register.  That should make it easier to see where a
>> value is first initialised.
>
> Thanks, that was bothering me too (but not enough to fix it).  Is there 
> any reason not to use a new register each time we do an assignment?

I'd wondered that too, and the final choice between mips_emit_binary
and mips_force_binary was a deliberate one.  ISTR we tended to add new
registers wherever possible in the past because the optimisers could
handle that better.  I think we're a lot better at handling register
reuse these days though, so putting every temporary result in a new
register would just slow things down.  (I'm more worried about the
cost of tracking more registers later than the cost of the gen_reg_rtx
call itself.)

Richard



More information about the Gcc-patches mailing list