[PATCH] D124247: [Trivial Dead] Consider any non volatile load as trivially dead independent on ordering

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 25 08:56:13 PDT 2022


efriedma added a comment.

> Do I understand correctly that here is the problem with exactly using of monotonic? If we used unordered (aka relaxed) then load2 can be safely removed?

In that example, yes.  If the first load isn't atomic, you'd have a race, which has undefined behavior.  If the first load is seq_cst, the second load is redundant, so it can be removed.

> So generally we should check all callers for this pattern which is likely not a good idea.

Right; it's very hard to detect cases where we can actually prove the safety.

> However if we could say that our language/runtime does not use monotonic atomic instructions (or do not use them for pointers from some addrspace or say for gc pointers) we are safe to remove such load?

If all memory ops in the program are seq_cst, it ends up being okay: every operation in the program is globally sequenced anyway, so a "dead" atomic op can't impose any additional ordering restrictions.  If you mix in non-atomic ops, it's more difficult to reason about, but I think you end up with a non-deterministic race in any other case where the "dead" atomic might matter.

I don't want to think about what happens if you mix in monotonic ops in other address-spaces.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124247/new/

https://reviews.llvm.org/D124247



More information about the llvm-commits mailing list