[PATCH] D65451: [DivRemPairs] Avoid RAUW pitfalls (PR42823)

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri created this revision.
lebedev.ri added reviewers: spatel, bogner, RKSimon, craig.topper.
lebedev.ri added a project: LLVM.
Herald added a subscriber: hiraditya.

`DivRemPairs` internally creates two maps:

- {sign, divident, divisor} -> div instruction
- {sign, divident, divisor} -> rem instruction

Then it iterates over rem map, and looks if there is an entry
in div map with the same key. Then depending on some internal logic
it may RAUW rem instruction with something else.

But if that rem instruction is an input to other div/rem,
then it was used as a key in these maps, so the old value (used in key)
is now dandling, because RAUW didn't update those maps.
And we can't even RAUW map keys in general, there's `ValueMap`,
but we don't have a single `Value` as key...

The bug was discovered via D65298 <https://reviews.llvm.org/D65298>, and the test there exists.
Now, i'm not sure how to expose this issue in trunk.
The bug is clearly there if i change the map keys to be `AssertingVH`/`PoisoningVH`,
but i guess this didn't miscompiled anything thus far?
I really don't think this is benin without that patch.

The fix is actually rather straight-forward - instead of trying to somehow
shoe-horn `ValueMap` here (doesn't fit, key isn't just `Value`), or writing a new
`ValueMap` with key being a struct of `Value`s, we can just have an intermediate
data structure - a vector, each entry containing `TrackingVH<Instruction> Div, Rem`,
and pre-filling it before doing any modifications.
Then RAUW will magically work due to the presence of `TrackingVH`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65451

Files:
  llvm/include/llvm/Transforms/Utils/BypassSlowDivision.h
  llvm/lib/Transforms/Scalar/DivRemPairs.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D65451.212337.patch
Type: text/x-patch
Size: 7695 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190730/999094c6/attachment-0001.bin>