[Top] [All Lists]

Re: MIPS atomic memory operations (A.K.A PR 33479).

To: "Maciej W. Rozycki" <>
Subject: Re: MIPS atomic memory operations (A.K.A PR 33479).
From: David Daney <>
Date: Wed, 19 Sep 2007 10:49:54 -0700
Cc: Ralf Baechle <>, Richard Sandiford <>, GCC Mailing List <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <>
User-agent: Thunderbird (X11/20070719)
Maciej W. Rozycki wrote:
On Wed, 19 Sep 2007, David Daney wrote:

Currently, I (and thus GCC 4.3) am assuming that Linux emulates 'll', 'sc' and
'sync', If sync is not emulated, we would need to adjust the code generation
so that it is not emitted on ISAs that don't support it.

While adding "sync" is trivial enough I may have a patch ready by tomorrow, that will not change the existing userbase and I am not entirely sure forcing such a hasty upgrade on people would be reasonable; likely not.

A workaround for a CPU erratum fits within the "-mfix-*" option family quite
well though.
Do we know which CPUs require branch-likely?

The R10000; there is a note about it in <asm-mips/war.h> at R10000_LLSC_WAR.

I would be inclined to agree with adding a "-mfix-??" option.

The only place where GCC's __sync_* primitives are generated without
explicitly writing them into your program is in GCJ compiled java code that
uses volatile fields.

If we expect the use of the __sync_* primitives on CPUs that require
branch-likely to be rare, we shouldn't penalize those trying to rid themselves
of the beasts.

Another option is to depend on the setting of -mbranch-likely. By default it is on only for the processors which implement it and do not discourage it, i.e. these of the MIPS II, MIPS III and MIPS IV ISAs.

This seems to be the most sensible option.

I will try to work up the GCC patch tonight.

David Daney

<Prev in Thread] Current Thread [Next in Thread>