diff options
| author | Sanjay Patel <spatel@rotateright.com> | 2018-06-02 16:27:44 +0000 |
|---|---|---|
| committer | Sanjay Patel <spatel@rotateright.com> | 2018-06-02 16:27:44 +0000 |
| commit | bbc6d60677c65aa8073c15b89aae353b192a472b (patch) | |
| tree | 05a11e1ebc58f842e9c6badb54f4e38950a9983c /llvm/tools/llvm-readobj/llvm-readobj.cpp | |
| parent | 51f19b9ee1d8469caeeeaf2b1774663ee50c6d69 (diff) | |
| download | bcm5719-llvm-bbc6d60677c65aa8073c15b89aae353b192a472b.tar.gz bcm5719-llvm-bbc6d60677c65aa8073c15b89aae353b192a472b.zip | |
[InstCombine] call simplify before trying vector folds
As noted in the review thread for rL333782, we could have
made a bug harder to hit if we were simplifying instructions
before trying other folds.
The shuffle transform in question isn't ever a simplification;
it's just a canonicalization. So I've renamed that to make that
clearer.
This is NFCI at this point, but I've regenerated the test file
to show the cosmetic value naming difference of using
instcombine's RAUW vs. the builder.
Possible follow-ups:
1. Move reassociation folds after simplifies too.
2. Refactor common code; we shouldn't have so much repetition.
llvm-svn: 333820
Diffstat (limited to 'llvm/tools/llvm-readobj/llvm-readobj.cpp')
0 files changed, 0 insertions, 0 deletions
