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

Serguei Katkov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 25 21:23:12 PDT 2022


skatkov added a comment.

Thanks, for you comment. Let me add details about my reasoning.
Let's we have load atomic %a with acquire or seq_cst semantic and this load has no uses.
According to specification this load has a ordering semantic only if it observes the value stored with release semantic to the same memory location.
If there is no uses then explicit check for is impossible. But it can be a implicit check like in example you mentioned.
So to do this implicit check we should load a value before our load and check its value. If our load must have the same value as previous load the previously loaded value may be used for such check.
Side note, let's consider there is only one store release to avoid mentioning "observe release store or later store" all the time.

So what this previous load may be:

1. Non atomic load - not interesting due to specification declares that atomic release store and non-atomic load is undefined behavior.
2. Atomic seq_cst or acquire load - if the previous such load already observes the store release our load is not required due to synchronization already happened and our load can be simply removed. If the previous load does not observe store release then it does not help to in implicit check.
3. Atomic monotonic load - according to your example definitely a problem. So if there is a monotonic load before our load, its check implicitly checks our load and we cannot eliminate our load.
4. Atomic unordered load - generally our acquire load does not prohibit moving other unordered load after our load (if it would be other memory location for sure and for the same location I guess also) and so it does not help in implicit check of our load.

So it looks like only usage of monotonic load before our load can be used for implicit check.
If it is true then we can probably add the following check in compiler:

  If the monotonic atomic load is not possible to be used for accessing the memory location used in our load then we can remove our load.

It can be done on different levels:

1. Add global flag that this complier does not use monotonic atomics.
2. Say for this addrspace compiler does not use monotonic atomics.
3. Say that for the current GC, gc pointers cannot be accessed with monotonic atomics.

In all cases verifier should be updated to ensure that monotonic loads are really not used for this type of pointers.

This is an idea. Do I miss anything?


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

https://reviews.llvm.org/D124247



More information about the llvm-commits mailing list