Bug 69618 - PowerPC/e6500: Atomic fence operations not properly supported
Summary: PowerPC/e6500: Atomic fence operations not properly supported
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-02 09:26 UTC by Sebastian Huber
Modified: 2022-03-08 16:20 UTC (History)
2 users (show)

See Also:
Host:
Target: powerpc
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Huber 2016-02-02 09:26:19 UTC
On the PowerPC/e6500 elemental synchronization operations should be used for acquire/release barriers. Currently a lwsync is used instead:

#include <stdatomic.h>

void release(void)
{
	atomic_thread_fence(memory_order_release);
}

void acquire(void)
{
	atomic_thread_fence(memory_order_acquire);
}

powerpc-rtems4.12-gcc -O2 -Wall -Wextra -pedantic -mcpu=e6500 -m32 -S fence.c
cat fence.s
        .file   "fence.c"
        .machine power4
        .section        ".text"
        .align 2
        .p2align 4,,15
        .globl release
        .type   release, @function
release:
        lwsync
        blr
        .size   release, .-release
        .align 2
        .p2align 4,,15
        .globl acquire
        .type   acquire, @function
acquire:
        lwsync
        blr
        .size   acquire, .-acquire
        .ident  "GCC: (GNU) 6.0.0 20160202 (experimental)

See also e6500 Core Reference Manual, 5.5.5.2.1 (Simplified memory barrier recommendations) and EREF: A Programmer’s Reference Manual for Freescale Power Architecture Processors (06/2014), 7.4.8.3 (Forcing Load and Store Ordering (Memory Barriers)).

For acquire semantic a "ESYNC 12" instruction should be used (Load-Load- and Load-Store-Barriere) and for release semantic a "ESYNC 5" instruction (Store-Store- and Load-Store-Barrier). See also Memory Model Rationales, section "Why ordering constraints are never limited to loads or stores" (www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html).

The e6500 core honours in contrast to the general PowerPC architecture a Load-Store-Ordering (EREF, 7.4.8.2 (Architecture Ordering Requirements), number 4), so maybe for acquire semantic "ESYNC 8" instruction (Load-Load-Barrier) and for release semantic a "ESYNC 1" instruction is sufficient (Store-Store-Barrier). See EREF, 7.4.8.4 (Architectural Memory Access Ordering), 7.4.8.6.1 (Acquire Lock and Import Shared Memory) and 7.4.8.7.1 (Export Shared Memory and Release Lock).