Re: [PATCH] MIPS: Loongson, workaround ll/sc weak ordering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Paul Burton <paul.burton@xxxxxxxx> 于2018年12月15日周六 下午12:52写道:
>
> Hi Maciej,
>
> On Fri, Dec 14, 2018 at 11:21:58PM +0000, Maciej W. Rozycki wrote:
> > On Fri, 14 Dec 2018, Paul Burton wrote:
> > > > We provides a config-time option for gcc. So whether
> > > > fix-loongson3-llsc option will be default,
> > > > is not sure. It depends on distributions.
> > >
> > > OK but even if it's default on, will that only apply when we provide
> > > -march=loongson3a? Surely it makes no sense to default on for other
> > > CPUs.
> >
> >  GCC defaults chosen at the configuration time apply regardless of any
> > `-march=' command-line option used with a given compilation (of course
> > unless the architecture selected actually precludes the use of the
> > affected instructions or code sequences), and I think it does make sense,
> > as this way you can have a compiler that defaults to some generic
> > architecture with all the workarounds enabled, which produces code safe to
> > run anywhere.
>
> Ah, thanks for the explanation, and I agree - that does make sense.
>
> >  I could envisage an option like `-mfix-loongson3-llsc=from-arch' or a
> > broader `-mfix=from-arch' one, and a corresponding set of GCC defaults to
> > choose from at the configuration time, however generic support for that
> > hasn't been implemented.  You could file an enhancement request with GCC
> > bugzilla to have a MIPS GCC port maintainer look into it I suppose.  It
> > should be moderately easy to implement I believe.
>
> It's not a big deal, and there'd still presumably be the option for
> someone to configure the compiler to always enable the workaround so
> there's still some benefit to us being explicit about whether we want it
> enabled or not.
>

This build-time option make sense for distribution-makers, like Debian/Fedora.
If we wish to rebuild the whole archive with this workaround,
we can enable this option by default.

The side affect I can imagine is that, if a package, which has a very
strong build system,
and build for serevial times and for different hardware.
Of course, kernel is one example, and in fact Debian's glibc package
can also do like this.

If the packages like this, we have to patch it to disable this option
by hand, just like we do
for kernel here.

Instead of the above, another option for distribution, is only build
some packages with this option,
since few packages has its own lock operation -- most of them use the
lock operation from libc/libatomic.

> >  IIRC not all `-mfix-foo' command-line options have a corresponding GCC
> > configuration option, in which case they default to off.
>
> Thanks a lot for clarifying,
>
>     Paul


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux