On Fri, Dec 12, 2014 at 10:56:26PM +0100, Ola Liljedahl wrote:
> On 12 December 2014 at 16:59, Mike Holmes <mike.hol...@linaro.org> wrote:
> >
> >
> > On 12 December 2014 at 10:51, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> >>
> >> On 12/12/2014 06:47 PM, Taras Kondratiuk wrote:
> >>>
> >>> On 12/12/2014 05:03 PM, Maxim Uvarov wrote:
> >>>>
> >>>> Odp atomic operations based on compiler build-ins. Make
> >>>> sure that compiler supports such operation at configure
> >>>> stage.
> >>>
> >>> This check should be limited to platforms that use gcc atomics.
> >>
> >> Do we have such platforms?
> >
> >
> > __OCTEON__ directly swappes out gcc, infact that pre processor switch
> > affects other files in linux-generic too.
> >
> > static inline uint32_t odp_atomic_fetch_inc_u32(odp_atomic_u32_t *atom)
> > {
> > #if defined __OCTEON__
> >>-------uint32_t ret;
> >>-------__asm__ __volatile__ ("syncws");
> >>-------__asm__ __volatile__ ("lai %0,(%2)" : "=r" (ret), "+m" (atom) :
> >>------->------->------- "r" (atom));
> >>-------return ret;
> > #else
> >>-------return __atomic_fetch_add(&atom->v, 1, __ATOMIC_RELAXED);
> > #endif
> > }
> This is an OCTEON-special for just one function. I didn't want to
> remove it. But I am not sure it is actually needed. Shouldn't the
> compiler be able to generate the appropriate OCTEON-specific
> instructions (e.g. laa(d), saa(d), lai(d), lad(d) etc), gcc has
> supported OCTEON since version 4.4? Also I don't understand the reason
> for the syncw *before* the lai (load-atomic-increment) but perhaps the
> load-atomic instructions (which shouldn't linger in the write buffer
> like stores) need to be treated differently.
I generated the dis-assembly of octeon gcc generated output,
Compiler does generate appropriate instruction for __atomic_fetch* instructions.
and if the contract is "__ATOMIC_RELAXED" then "syncws" can be removed.
Typical use case for putting "syncw" before the lai operation to make sure
cpu does not change the order of "lai" and "instructions before it"
as octeon is weakly ordered cpu for better performance.
>
> I think this OCTEON-fix should either be removed or there should be
> specials for most if not all of the functions in odp_atomic.h
Yes, It can be removed if the contract is "__ATOMIC_RELAXED".
Do we have any specific reason to keep the API as odp_atomic_*, if its
an "__ATOMIC_RELAXED" memory model then its better to rename as counters.
> >
> >
> >>
> >>
> >>
> >> Maxim.
> >>
> >>
> >> _______________________________________________
> >> lng-odp mailing list
> >> lng-odp@lists.linaro.org
> >> http://lists.linaro.org/mailman/listinfo/lng-odp
> >
> >
> >
> > --
> > Mike Holmes
> > Linaro Sr Technical Manager
> > LNG - ODP
> >
> > _______________________________________________
> > lng-odp mailing list
> > lng-odp@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/lng-odp
> >
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
