diff options
| author | David Majnemer <david.majnemer@gmail.com> | 2016-07-18 06:11:37 +0000 |
|---|---|---|
| committer | David Majnemer <david.majnemer@gmail.com> | 2016-07-18 06:11:37 +0000 |
| commit | 04c7c225a12e5857ad01dac3c1d63fb256c4b07c (patch) | |
| tree | eab679d9c6c18ca888c2ad486a6f1baa0980b217 /llvm/lib/Target | |
| parent | 16be8ee1fff9793becfde9d9815b257aadce1ca3 (diff) | |
| download | bcm5719-llvm-04c7c225a12e5857ad01dac3c1d63fb256c4b07c.tar.gz bcm5719-llvm-04c7c225a12e5857ad01dac3c1d63fb256c4b07c.zip | |
[GVNHoist] Change the key for VNtoInsns to a pair
While debugging GVNHoist, I found it confusing that the entries in a
VNtoInsns were not always value numbers. They _usually_ were except for
StoreInst in which case they were a hash of two different value numbers.
This leads to two observations:
- It is more difficult to debug things when the semantic contents of
VNtoInsns changes over time.
- Using a single value number is not much cheaper, the value of
VNtoInsns is a SmallVector.
- It is not immediately clear what the algorithm would do if there were
hash collisions in the StoreInst case.
Using a DenseMap of std::pair sidesteps all of this.
N.B. The changes in the test were due their sensitivity to the
iteration order of VNtoInsns which has changed.
llvm-svn: 275761
Diffstat (limited to 'llvm/lib/Target')
0 files changed, 0 insertions, 0 deletions

