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? Richard. > > jeff
