maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/InstCombine/high-bit-signmask.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

127 lines
3.1 KiB
LLVM
Raw Normal View History

[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt %s -instcombine -S | FileCheck %s
define i64 @t0(i64 %x) {
; CHECK-LABEL: @t0(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr i64 [[X:%.*]], 63
; CHECK-NEXT: ret i64 [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = lshr i64 %x, 63
%r = sub i64 0, %t0
ret i64 %r
}
define i64 @t0_exact(i64 %x) {
; CHECK-LABEL: @t0_exact(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr exact i64 [[X:%.*]], 63
; CHECK-NEXT: ret i64 [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = lshr exact i64 %x, 63
%r = sub i64 0, %t0
ret i64 %r
}
define i64 @t2(i64 %x) {
; CHECK-LABEL: @t2(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = lshr i64 [[X:%.*]], 63
; CHECK-NEXT: ret i64 [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = ashr i64 %x, 63
%r = sub i64 0, %t0
ret i64 %r
}
define i64 @t3_exact(i64 %x) {
; CHECK-LABEL: @t3_exact(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = lshr exact i64 [[X:%.*]], 63
; CHECK-NEXT: ret i64 [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = ashr exact i64 %x, 63
%r = sub i64 0, %t0
ret i64 %r
}
define <2 x i64> @t4(<2 x i64> %x) {
; CHECK-LABEL: @t4(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr <2 x i64> [[X:%.*]], <i64 63, i64 63>
; CHECK-NEXT: ret <2 x i64> [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = lshr <2 x i64> %x, <i64 63, i64 63>
%r = sub <2 x i64> zeroinitializer, %t0
ret <2 x i64> %r
}
define <2 x i64> @t5(<2 x i64> %x) {
; CHECK-LABEL: @t5(
; CHECK-NEXT: [[T0:%.*]] = lshr <2 x i64> [[X:%.*]], <i64 63, i64 undef>
; CHECK-NEXT: [[R:%.*]] = sub <2 x i64> <i64 0, i64 undef>, [[T0]]
; CHECK-NEXT: ret <2 x i64> [[R]]
;
%t0 = lshr <2 x i64> %x, <i64 63, i64 undef>
%r = sub <2 x i64> <i64 0, i64 undef>, %t0
ret <2 x i64> %r
}
declare void @use64(i64)
declare void @use32(i64)
define i64 @t6(i64 %x) {
; CHECK-LABEL: @t6(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr i64 [[X:%.*]], 63
; CHECK-NEXT: [[T0:%.*]] = lshr i64 [[X]], 63
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
; CHECK-NEXT: call void @use64(i64 [[T0]])
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: ret i64 [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = lshr i64 %x, 63
call void @use64(i64 %t0)
%r = sub i64 0, %t0
ret i64 %r
}
define i64 @n7(i64 %x) {
; CHECK-LABEL: @n7(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr i64 [[X:%.*]], 63
; CHECK-NEXT: [[T0:%.*]] = lshr i64 [[X]], 63
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
; CHECK-NEXT: call void @use32(i64 [[T0]])
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: ret i64 [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = lshr i64 %x, 63
call void @use32(i64 %t0)
%r = sub i64 0, %t0
ret i64 %r
}
define i64 @n8(i64 %x) {
; CHECK-LABEL: @n8(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr i64 [[X:%.*]], 63
; CHECK-NEXT: [[T0:%.*]] = lshr i64 [[X]], 63
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
; CHECK-NEXT: call void @use64(i64 [[T0]])
; CHECK-NEXT: call void @use32(i64 [[T0]])
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: ret i64 [[T0_NEG]]
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
;
%t0 = lshr i64 %x, 63
call void @use64(i64 %t0)
call void @use32(i64 %t0)
%r = sub i64 0, %t0
ret i64 %r
}
define i64 @n9(i64 %x) {
; CHECK-LABEL: @n9(
; CHECK-NEXT: [[T0:%.*]] = lshr i64 [[X:%.*]], 62
; CHECK-NEXT: [[R:%.*]] = sub nsw i64 0, [[T0]]
; CHECK-NEXT: ret i64 [[R]]
;
%t0 = lshr i64 %x, 62
%r = sub i64 0, %t0
ret i64 %r
}
define i64 @n10(i64 %x) {
; CHECK-LABEL: @n10(
[InstCombine] Negator - sink sinkable negations Summary: As we have discussed previously (e.g. in D63992 / D64090 / [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]), `sub` instruction can almost be considered non-canonical. While we do convert `sub %x, C` -> `add %x, -C`, we sparsely do that for non-constants. But we should. Here, i propose to interpret `sub %x, %y` as `add (sub 0, %y), %x` IFF the negation can be sinked into the `%y` This has some potential to cause endless combine loops (either around PHI's, or if there are some opposite transforms). For former there's `-instcombine-negator-max-depth` option to mitigate it, should this expose any such issues For latter, if there are still any such opposing folds, we'd need to remove the colliding fold. In any case, reproducers welcomed! Reviewers: spatel, nikic, efriedma, xbolva00 Reviewed By: spatel Subscribers: xbolva00, mgorny, hiraditya, reames, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68408
2020-04-22 02:24:36 +08:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr i64 [[X:%.*]], 63
; CHECK-NEXT: [[R:%.*]] = add nsw i64 [[T0_NEG]], 1
[NFC][InstCombine] (Better) tests for sign-bit-smearing pattern https://rise4fun.com/Alive/JRU https://rise4fun.com/Alive/yR4 <- we can preserve 'exact' llvm-svn: 373362
2019-10-02 01:49:58 +08:00
; CHECK-NEXT: ret i64 [[R]]
;
%t0 = lshr i64 %x, 63
%r = sub i64 1, %t0
ret i64 %r
}