Hi Andriy, On Wed, Sep 6, 2017 at 12:24 PM, Andriy Berestovskyy <andriy.berestovs...@caviumnetworks.com> wrote: > Hey Brian, > You are right, there are no compiler barriers on master, I just was on > api-next branch: > > https://git.linaro.org/lng/odp.git/tree/platform/linux-generic/arch/arm/odp_atomic.h?h=api-next#n56
How about a #define for compiler barrier in odp_compiler_internal.h? > Andriy > > > On 05.09.2017 17:06, Brian Brooks wrote: >> >> I don't see a compiler barrier in the odp.git repo. Perhaps 'nop', but >> this acts as more than a pure compiler barrier? >> >> >> On Tue, Sep 5, 2017 at 8:23 AM, Andriy Berestovskyy >> <andriy.berestovs...@caviumnetworks.com> wrote: >>> >>> Hey Petri, >>> >>> On 05.09.2017 14:17, Savolainen, Petri (Nokia - FI/Espoo) wrote: >>>> >>>> >>>> I think compiler barrier is too weak for writing portable code, since it >>>> does not guarantee that the CPU would not re-order the instructions. >>> >>> >>> >>> >>> No, compiler barrier does not guarantee CPU order. Though, sometimes we >>> do >>> not need such a guarantee. >>> >>> Compiler barriers are in the same league with volatiles and provide the >>> same >>> weak guarantees: eventually the effect will be observed and code will not >>> be >>> optimized out by the compiler. >>> >>> >>> >>>> ODP implementation has ":::memory" in context of inline assembly >>>> instructions, but that's when we are writing code against specific ISA >>>> and >>>> thus know which amount of synchronization is needed. >>> >>> >>> >>> >>> The barrier is quite rare, so it might remain in form of asm volatile... >>> >>> >>> Andriy
