summaryrefslogtreecommitdiffstats
path: root/llvm/test/Transforms/InstCombine/shift-amount-reassociation-with-truncation-lshr.ll
Commit message (Collapse)AuthorAgeFilesLines
* [NFC][InstCombine] More test for "sign bit test via shifts" pattern (PR43595)Roman Lebedev2019-10-131-2/+24
| | | | | | | | | | | | | | | | While that pattern is indirectly handled via reassociateShiftAmtsOfTwoSameDirectionShifts(), that incursme one-use restriction on truncation, which is pointless since we know that we'll produce a single instruction. Additionally, *if* we are only looking for sign bit, we don't need shifts to be identical, which isn't the case in general, and is the blocker for me in bug in question: https://bugs.llvm.org/show_bug.cgi?id=43595 llvm-svn: 374726
* [InstCombine] Right-shift shift amount reassociation with truncation ↵Roman Lebedev2019-10-041-38/+15
| | | | | | | | | | | | | | | | | | | (PR43564, PR42391) Initially (D65380) i believed that if we have rightshift-trunc-rightshift, we can't do any folding. But as it usually happens, i was wrong. https://rise4fun.com/Alive/GEw https://rise4fun.com/Alive/gN2O In https://bugs.llvm.org/show_bug.cgi?id=43564 we happen to have this very sequence, of two right shifts separated by trunc. And "just" so that happens, we apparently can fold the pattern if the total shift amount is either 0, or it's equal to the bitwidth of the innermost widest shift - i.e. if we are left with only the original sign bit. Which is exactly what is wanted there. llvm-svn: 373801
* [NFC][InstCombine] Tests for right-shift shift amount reassociation (w/ ↵Roman Lebedev2019-10-041-0/+201
trunc) (PR43564, PR42391) https://rise4fun.com/Alive/GEw llvm-svn: 373797
OpenPOWER on IntegriCloud