Remove unused atomic loads without ordering requirements

[tmatheson-arm]

https://godbolt.org/z/TYrzds3dT

#include <atomic>

std::atomic<uint64_t> x;
uint64_t y;

void atomic() {
    uint64_t unused = x.load(std::memory_order_relaxed);
}

void nonatomic() {
    uint64_t unused = y;
}

For atomic(), the load is generated as load atomic i64, ptr @x monotonic whereas for nonatomic() it is already optimised out. The load here has no ordering constraints, so for aarch64 (and other targets) this results in an unnecessary load operation:

atomic():
        adrp    x8, x
        ldr     xzr, [x8, :lo12:x]
        ret

nonatomic():
        ret

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Tomas Matheson (tmatheson-arm)

https://godbolt.org/z/TYrzds3dT

#include <atomic>

std::atomic<uint64_t> x;
uint64_t y;

void atomic() {
    uint64_t unused = x.load(std::memory_order_relaxed);
}

void nonatomic() {
    uint64_t unused = y;
}

For atomic(), the load is generated as load atomic i64, ptr @<!-- -->x monotonic whereas for nonatomic() it is already optimised out. The load here has no ordering constraints, so for aarch64 (and other targets) this results in an unnecessary load operation:

atomic():
        adrp    x8, x
        ldr     xzr, [x8, :lo12:x]
        ret

nonatomic():
        ret

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Tomas Matheson (tmatheson-arm)

https://godbolt.org/z/TYrzds3dT

#include <atomic>

std::atomic<uint64_t> x;
uint64_t y;

void atomic() {
    uint64_t unused = x.load(std::memory_order_relaxed);
}

void nonatomic() {
    uint64_t unused = y;
}

For atomic(), the load is generated as load atomic i64, ptr @<!-- -->x monotonic whereas for nonatomic() it is already optimised out. The load here has no ordering constraints, so for aarch64 (and other targets) this results in an unnecessary load operation:

atomic():
        adrp    x8, x
        ldr     xzr, [x8, :lo12:x]
        ret

nonatomic():
        ret

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Tomas Matheson (tmatheson-arm)

https://godbolt.org/z/TYrzds3dT

#include <atomic>

std::atomic<uint64_t> x;
uint64_t y;

void atomic() {
    uint64_t unused = x.load(std::memory_order_relaxed);
}

void nonatomic() {
    uint64_t unused = y;
}

For atomic(), the load is generated as load atomic i64, ptr @<!-- -->x monotonic whereas for nonatomic() it is already optimised out. The load here has no ordering constraints, so for aarch64 (and other targets) this results in an unnecessary load operation:

atomic():
        adrp    x8, x
        ldr     xzr, [x8, :lo12:x]
        ret

nonatomic():
        ret

[antoniofrighetto]

Hmm, wouldn't one need to prove that there are no acquire fences that partecipate in the synchronization with the relaxed load beyond the function itself? I don't think the current dead code elimination procedures in LLVM reason interprocedurally.

[tmatheson-arm]

Of course, you are right. I could not see why it mattered with such a reduced example, but any other memory ops before/after the monotonic load would be ordered by a release/acquire fence too.