On 3/26/2026 7:37 AM, Richard Biener wrote:
On Thu, Mar 26, 2026 at 2:30 PM Jeffrey Law
<[email protected]> wrote:
On 3/26/2026 2:44 AM, Eikansh Gupta wrote:
A relaxed atomic load whose result is never used has no observable
effect: the value is discarded and __ATOMIC_RELAXED provides no
inter-thread synchronisation guarantee.
Fix this by adding an early-return check for
BUILT_IN_ATOMIC_LOAD_1/2/4/8/16 calls that have no LHS and a
compile-time-constant relaxed memory order.
PR tree-optimization/123966
gcc/ChangeLog:
* tree-ssa-dce.cc (mark_stmt_if_obviously_necessary):
Don't mark a relaxed atomic load with no LHS as necessary.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr123966.c: New test.
This is almost exactly what I've got here waiting for gcc-17. You've got
a more complete testcase, so let's make yours the canonical variant
going forward.
+ /* A relaxed atomic load with no LHS has no observable effect:
+ the value is discarded and relaxed ordering provides no
+ inter-thread synchronisation guarantee. Don't mark it
+ necessary so DCE can remove it. */
+ if (!gimple_call_lhs (call)
+ && gimple_call_builtin_p (call, BUILT_IN_NORMAL))
This is the only functional difference relative to my variant. I would
drop the !gimple_call_lhs test.
Consider if the call has an LHS, but the LHS has become unused due to
the actions of a prior pass. We would mark the relaxed load as
inherently necessary. After that we run the core DCE algorithm which
would remove the LHS argument if it was determined it was unused
(eliminate_unnecessary_stmts). But the actual relaxed load would still
be lying around because it had been marked as inherently necessary.
Instead just drop the test. That allows us to handle a relaxed memory
load just like any other memory load (which I think is the right mental
model for relaxed loads, treat them just like any other load, except
that they have to be atomic).
OK for gcc-17 with that change.
Another thing, if there's really no order constraints imposed by those
loads would be to handle those from builtin_fnspec so we can
optimize other memory operations around them. If they do impose
ordering constraints how can we DCE them at all?
Relaxed does not imply ordering. It's just forces the memory operation
to be atomic. We don't take advantage of that in various places where
we could/should. DCE just happens to have stuck out because there's hot
code in jemalloc with a dead atomic load and fixing it is easy.
Jeff
