diff options
| author | Roman Lebedev <lebedev.ri@gmail.com> | 2019-06-26 12:19:11 +0000 |
|---|---|---|
| committer | Roman Lebedev <lebedev.ri@gmail.com> | 2019-06-26 12:19:11 +0000 |
| commit | 8b9a03973aae23b2e32cea3b72582123a16ef9e0 (patch) | |
| tree | 549782360b2317fa0f63169d9f047482fd089f1c /llvm/lib/Analysis | |
| parent | 2851248fa14119a59f9262ae91fb2c06baa59ea3 (diff) | |
| download | bcm5719-llvm-8b9a03973aae23b2e32cea3b72582123a16ef9e0.tar.gz bcm5719-llvm-8b9a03973aae23b2e32cea3b72582123a16ef9e0.zip | |
[X86] X86DAGToDAGISel::matchBitExtract(): pattern a: truncation awareness
Summary:
Finally tying up loose ends here.
The problem is quite simple:
If we have pattern `(x >> start) & (1 << nbits) - 1`,
and then truncate the result, that truncation will be propagated upwards,
into the `and`. And that isn't currently handled.
I'm only fixing pattern `a` here,
the same fix will be needed for patterns `b`/`c` too.
I *think* this isn't missing any extra legality checks,
since we only look past truncations. Similary, i don't think
we can get any other truncation there other than i64->i32.
Reviewers: craig.topper, RKSimon, spatel
Reviewed By: craig.topper
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62786
llvm-svn: 364417
Diffstat (limited to 'llvm/lib/Analysis')
0 files changed, 0 insertions, 0 deletions

