I am working on a project that requires LLVM DeadStoreElimination
However, when I look through the code in Transforms/Scalar/DeadStoreElimination.cpp, I see the following:
// Ignore any store where we can't find a local dependence.
// FIXME: cross-block DSE would be fun.
if (!InstDep.isDef() && !InstDep.isClobber())
continue;
I have two questions on this code:I have two questions on this code:
1. What is a clobber?
2. Does the local dependence mean that the dependence should reside in the same basic bloWhat does the comment (FIXME: cross-block DSE would be fun) mean in this case?
Let's say we have a query instruction which references a memory location. A
clobber is an instruction which may update the value in that memory location,
i.e it's a dependency of the query instruction.
Here are some specific examples of clobbers:
- A volatile load which precedes the query instruction.
- A load which precedes a possibly-volatile query instruction.
- An instruction which updates a memory location Mod/Ref'd by a call.
- Some atomic loads are always considered to be clobbers. Ditto for atomic
stores. You'll have to look at the source for details about the ordering
requirements. Note that the comments claim that llvm is more conservative
here than it needs to be.
- Any volatile store. This is also more conservative than it needs to be --
there's a FIXME about it.
- A store that may-alias the query instruction.
Loads which partially-alias the query instruction aren't treated as clobbers.
The docs in MemDepResult mention that this is an interesting case but I'm not
sure why. It looks like this behavior was disabled in r132631.
2. Does the local dependence mean that the dependence should reside in the same basic bloWhat does the comment (FIXME: cross-block DSE would be fun) mean in this case?
Yes, in this context, DSE is querying MemDep for a dependency which has a
memory write. MemDep can either return a Def, a Clobber, or an Other. Other
means that the query instruction has no known dependency in the current basic
block.
The "FIXME" is saying that it could be worthwhile to look for dependencies in
blocks which are post-dominated by the current block. If you want to see an
example of how this could be done, take a look at the implementation of
handleFree(). Note that instead of using post-dominators, it looks at the
unconditional predecessors of the block containing the free.
