RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 18:54:02 +01:00
Code Issues Projects Releases Wiki Activity
bedf13b1a7
llvm-mirror/test/Transforms/InstCombine/high-bit-signmask-with-trunc.ll

149 lines
4.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-01 19:49:58 +02:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
[InstCombine] use redirect of input file in regression tests; NFC This is a repeat of 1880092722 from 2009. We should have less risk of hitting bugs at this point because we auto-generate positive CHECK lines only, but this makes things consistent. Copying the original commit msg: "Change tests from "opt %s" to "opt < %s" so that opt doesn't see the input filename so that opt doesn't print the input filename in the output so that grep lines in the tests don't unintentionally match strings in the input filename."
2020-09-29 17:02:03 +02:00
; RUN: opt < %s -instcombine -S | FileCheck %s
[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-01 19:49:58 +02:00
define i32 @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-21 20:24:36 +02:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr i64 [[X:%.*]], 63
; CHECK-NEXT: [[T1_NEG:%.*]] = trunc i64 [[T0_NEG]] to i32
; CHECK-NEXT: ret i32 [[T1_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-01 19:49:58 +02:00
;
%t0 = lshr i64 %x, 63
%t1 = trunc i64 %t0 to i32
%r = sub i32 0, %t1
ret i32 %r
}
define i32 @t1_exact(i64 %x) {
; CHECK-LABEL: @t1_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-21 20:24:36 +02:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr exact i64 [[X:%.*]], 63
; CHECK-NEXT: [[T1_NEG:%.*]] = trunc i64 [[T0_NEG]] to i32
; CHECK-NEXT: ret i32 [[T1_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-01 19:49:58 +02:00
;
%t0 = lshr exact i64 %x, 63
%t1 = trunc i64 %t0 to i32
%r = sub i32 0, %t1
ret i32 %r
}
define i32 @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-21 20:24:36 +02:00
; CHECK-NEXT: [[T0_NEG:%.*]] = lshr i64 [[X:%.*]], 63
; CHECK-NEXT: [[T1_NEG:%.*]] = trunc i64 [[T0_NEG]] to i32
; CHECK-NEXT: ret i32 [[T1_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-01 19:49:58 +02:00
;
%t0 = ashr i64 %x, 63
%t1 = trunc i64 %t0 to i32
%r = sub i32 0, %t1
ret i32 %r
}
define i32 @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-21 20:24:36 +02:00
; CHECK-NEXT: [[T0_NEG:%.*]] = lshr exact i64 [[X:%.*]], 63
; CHECK-NEXT: [[T1_NEG:%.*]] = trunc i64 [[T0_NEG]] to i32
; CHECK-NEXT: ret i32 [[T1_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-01 19:49:58 +02:00
;
%t0 = ashr exact i64 %x, 63
%t1 = trunc i64 %t0 to i32
%r = sub i32 0, %t1
ret i32 %r
}
define <2 x i32> @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-21 20:24:36 +02:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr <2 x i64> [[X:%.*]], <i64 63, i64 63>
; CHECK-NEXT: [[T1_NEG:%.*]] = trunc <2 x i64> [[T0_NEG]] to <2 x i32>
; CHECK-NEXT: ret <2 x i32> [[T1_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-01 19:49:58 +02:00
;
%t0 = lshr <2 x i64> %x, <i64 63, i64 63>
%t1 = trunc <2 x i64> %t0 to <2 x i32>
%r = sub <2 x i32> zeroinitializer, %t1
ret <2 x i32> %r
}
define <2 x i32> @t5(<2 x i64> %x) {
; CHECK-LABEL: @t5(
; CHECK-NEXT: [[T0:%.*]] = lshr <2 x i64> [[X:%.*]], <i64 63, i64 undef>
; CHECK-NEXT: [[T1:%.*]] = trunc <2 x i64> [[T0]] to <2 x i32>
; CHECK-NEXT: [[R:%.*]] = sub <2 x i32> <i32 0, i32 undef>, [[T1]]
; CHECK-NEXT: ret <2 x i32> [[R]]
;
%t0 = lshr <2 x i64> %x, <i64 63, i64 undef>
%t1 = trunc <2 x i64> %t0 to <2 x i32>
%r = sub <2 x i32> <i32 0, i32 undef>, %t1
ret <2 x i32> %r
}
declare void @use64(i64)
declare void @use32(i32)
define i32 @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-21 20:24:36 +02: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-01 19:49:58 +02: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-21 20:24:36 +02:00
; CHECK-NEXT: [[T1_NEG:%.*]] = trunc i64 [[T0_NEG]] to i32
; CHECK-NEXT: ret i32 [[T1_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-01 19:49:58 +02:00
;
%t0 = lshr i64 %x, 63
call void @use64(i64 %t0)
%t1 = trunc i64 %t0 to i32
%r = sub i32 0, %t1
ret i32 %r
}
define i32 @n7(i64 %x) {
; CHECK-LABEL: @n7(
; CHECK-NEXT: [[T0:%.*]] = lshr i64 [[X:%.*]], 63
; CHECK-NEXT: [[T1:%.*]] = trunc i64 [[T0]] to i32
; CHECK-NEXT: call void @use32(i32 [[T1]])
; CHECK-NEXT: [[R:%.*]] = sub nsw i32 0, [[T1]]
; CHECK-NEXT: ret i32 [[R]]
;
%t0 = lshr i64 %x, 63
%t1 = trunc i64 %t0 to i32
call void @use32(i32 %t1)
%r = sub i32 0, %t1
ret i32 %r
}
define i32 @n8(i64 %x) {
; CHECK-LABEL: @n8(
; CHECK-NEXT: [[T0:%.*]] = lshr i64 [[X:%.*]], 63
; CHECK-NEXT: call void @use64(i64 [[T0]])
; CHECK-NEXT: [[T1:%.*]] = trunc i64 [[T0]] to i32
; CHECK-NEXT: call void @use32(i32 [[T1]])
; CHECK-NEXT: [[R:%.*]] = sub nsw i32 0, [[T1]]
; CHECK-NEXT: ret i32 [[R]]
;
%t0 = lshr i64 %x, 63
call void @use64(i64 %t0)
%t1 = trunc i64 %t0 to i32
call void @use32(i32 %t1)
%r = sub i32 0, %t1
ret i32 %r
}
define i32 @n9(i64 %x) {
; CHECK-LABEL: @n9(
; CHECK-NEXT: [[T0:%.*]] = lshr i64 [[X:%.*]], 62
; CHECK-NEXT: [[T1:%.*]] = trunc i64 [[T0]] to i32
; CHECK-NEXT: [[R:%.*]] = sub nsw i32 0, [[T1]]
; CHECK-NEXT: ret i32 [[R]]
;
%t0 = lshr i64 %x, 62
%t1 = trunc i64 %t0 to i32
%r = sub i32 0, %t1
ret i32 %r
}
define i32 @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-21 20:24:36 +02:00
; CHECK-NEXT: [[T0_NEG:%.*]] = ashr i64 [[X:%.*]], 63
; CHECK-NEXT: [[T1_NEG:%.*]] = trunc i64 [[T0_NEG]] to i32
; CHECK-NEXT: [[R:%.*]] = add i32 [[T1_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-01 19:49:58 +02:00
; CHECK-NEXT: ret i32 [[R]]
;
%t0 = lshr i64 %x, 63
%t1 = trunc i64 %t0 to i32
%r = sub i32 1, %t1
ret i32 %r
}
Reference in New Issue Copy Permalink