This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] mips: work-around R10k ll/sc errata


On Wed, Jun 29, 2011 at 10:39 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 28 Jun 2011, Matt Turner wrote:
>
>> This was sent back in Nov 2008 by Joshua Kinard, but seems to have
>> fallen through the cracks after a lot of bikeshedding.
>>
>> I don't particularly care about implementing alternative work-arounds,
>> like 28 nops. I only intend for this patch to be useful when the builder
>> is using -march=r10000 and/or -mfix-r10000. All other situations are
>> unaffected.
>
> I think the discussion really illustrates that glibc isn't the right place
> to be making this decision; there are a lot of different compiler options
> for different MIPS variants, and I don't know if they all have relevant
> preprocessor macros, and the compiler already makes its own decisions
> based on those options about how to implement __sync_*. ?There are also
> various out-of-tree patches to the MIPS atomics in glibc to optimize them
> for some processor variants.
>
> The real fix is to use __sync_* for MIPS in glibc, as done for some other
> architectures. ?But for this not to be an optimization regression you need
> versions of those functions with more specific barrier semantics. ?Tom,
> you had such functions (MIPS-specific) and associated glibc changes. ?A
> proper set of target-independent such functions has recently been
> discussed on gcc-patches by Aldy Hernandez, Andrew MacLeod et al; once the
> generic framework is in GCC trunk, perhaps you could contribute a version
> of your MIPS changes that builds on the generic framework, and then a
> version of the glibc patches that uses the new generic builtins? ?The
> existing assembly implementations can then be left just for GCC <= 4.6,
> and not complicated by lots of processor conditionals.

I agree -- using __sync_* would certainly remove any of this
complexity from glibc and is the way to go.

Unfortunately, GCC <= 4.6 is going to be around for a while. The patch
is noninvasive and only modifies the code in one very specific (and
currently broken) case. Would you mind if it were committed, at least
until the __sync_*-based implementation is committed?

Thanks for the feedback,
Matt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]