This patch forces a sequence point when comparing the values from a DenseMap.
In particular, there is a comparison in GVN::performScalarPRE that accesses the
same DenseMap via two different keys in the same expression.
This patch preserves the intended semantics, but forces a sequence point and store of
the map's values. Since DenseMap does not invalidate it's pointers, it looks like
we might want to fix how we present the conditional, in particular, what this patch solves.
I'm opening this patch upe original patch addressed the use of BlockRPONumber by forcing a sequence point when accessing that map in a conditional. In short we found cases where that map was being accessed with blocks that had not yet been added to that structure. For context, mainly for discussion.I've kept the wall of text below, I realize a decent reproducer test is probably
warrantedto what we are trying to fix, but I have been unable to create a reliable reproducerby always ensuring a updated BlockRPONumber.
== Backstory ==
I was investigating an ICE (segfault accessing a DenseMap item). This failure happened periodnon-deterministically, with no apparent reason and only on a Windows build of LLVM (from October 2018).
After looking into the crashes (multiple core files) and running DynamoRio, the cores and DynamoRio (DR) log pointed to the same code in `GVN::performScalarPRE()`. The values in the map are unsigned integers, the keys are `llvm::BasicBlock*`. Our test case that triggered this warning and periodic crash is rather involved. But the problematic line looks to be:
GVN.cpp: Line 2197
if (BlockRPONumber[P] >= BlockRPONumber[CurrentBlock] &&
Just to test things outTo test things out, I cooked up a patch that accessed the items in the map outside of the condition, I cooked up this patch (for our llvm branch that was breaking)by forcing a sequence point between accesses. DynamoRio stopped warning of the issue, and the test didn't seem to crash after 1000+ runs.
My investigation was on an older version of LLVM, (source from October this year). What it looks like was occurring is the following, and the assembly from the latest pull of llvm todayin December seems to confirm this might still be an issue; however, I have not witnessed the crash on more recent builds. Of course the asm in question is generated from the host compiler on that Windows box (not clang), but it hints that we might want to consider how we access the BlockRPONumber map in this conditional (line 2197, listed above). In any case, I don't think the host compiler is wrong, rather I think it is pointing out a possibly latent bug in llvm.
1) There is no sequence point for the `>=` operation.
2) A call to a `DenseMapBase::operator` can have the side effect of the map reallocating a larger store (more Buckets, via a call to `DenseMap::grow`).
3) It seems perfectly legal for a host compiler to generate assembly that stores the result of a call to `operator` on the stack (that's what my host compile of GVN.cpp is doing) . A second call to `operator` //might// encourage the map to 'grow' thus making any pointers to the map's store invalid. The `>=` compares the first and second values. If the first happens to be a pointer produced from operator, it could be invalid when dereferenced at the time of comparison.
In any case, I do think the safest thing to do is implement this patch. It's simple and adheres to the intended semantics.
Now, this could be a red herring (e.g., perhaps performScalarPRE is called and GVN::assignBlockRPONumber() was never called).
But after this patch, the error and warnings seem to go away on that problematic branch of llvm.
The assembly generated from the Window's host compiler does show the result of the first access to the map via `operator` produces a pointer to an unsigned int. And that pointer is being stored on the stack. If a second call to the map (which does occur) causes the map to grow, that address (on the stack) is now invalid.