maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/PowerPC/sub-of-not.ll

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

436 lines
14 KiB
LLVM
Raw Normal View History

[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=ppc32-unknown-unknown | FileCheck %s --check-prefixes=ALL,PPC32
; RUN: llc < %s -mtriple=powerpc64-unknown-unknown | FileCheck %s --check-prefixes=ALL,PPC64,PPC64BE
; RUN: llc < %s -mtriple=powerpc64le-unknown-unknown | FileCheck %s --check-prefixes=ALL,PPC64,PPC64LE
; These two forms are equivalent:
; sub %y, (xor %x, -1)
; add (add %x, 1), %y
; Some targets may prefer one to the other.
define i8 @scalar_i8(i8 %x, i8 %y) nounwind {
; ALL-LABEL: scalar_i8:
; ALL: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; ALL-NEXT: add 3, 4, 3
; ALL-NEXT: addi 3, 3, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; ALL-NEXT: blr
%t0 = xor i8 %x, -1
%t1 = sub i8 %y, %t0
ret i8 %t1
}
define i16 @scalar_i16(i16 %x, i16 %y) nounwind {
; ALL-LABEL: scalar_i16:
; ALL: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; ALL-NEXT: add 3, 4, 3
; ALL-NEXT: addi 3, 3, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; ALL-NEXT: blr
%t0 = xor i16 %x, -1
%t1 = sub i16 %y, %t0
ret i16 %t1
}
define i32 @scalar_i32(i32 %x, i32 %y) nounwind {
; ALL-LABEL: scalar_i32:
; ALL: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; ALL-NEXT: add 3, 4, 3
; ALL-NEXT: addi 3, 3, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; ALL-NEXT: blr
%t0 = xor i32 %x, -1
%t1 = sub i32 %y, %t0
ret i32 %t1
}
define i64 @scalar_i64(i64 %x, i64 %y) nounwind {
; PPC32-LABEL: scalar_i64:
; PPC32: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: addc 4, 6, 4
; PPC32-NEXT: adde 3, 5, 3
; PPC32-NEXT: addic 4, 4, 1
; PPC32-NEXT: addze 3, 3
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC32-NEXT: blr
;
; PPC64-LABEL: scalar_i64:
; PPC64: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64-NEXT: add 3, 4, 3
; PPC64-NEXT: addi 3, 3, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC64-NEXT: blr
%t0 = xor i64 %x, -1
%t1 = sub i64 %y, %t0
ret i64 %t1
}
define <16 x i8> @vector_i128_i8(<16 x i8> %x, <16 x i8> %y) nounwind {
; PPC32-LABEL: vector_i128_i8:
; PPC32: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: stwu 1, -64(1)
; PPC32-NEXT: stw 21, 20(1) # 4-byte Folded Spill
; PPC32-NEXT: lbz 21, 123(1)
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: stw 22, 24(1) # 4-byte Folded Spill
; PPC32-NEXT: stw 23, 28(1) # 4-byte Folded Spill
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: add 7, 21, 7
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: lbz 23, 115(1)
; PPC32-NEXT: lbz 22, 119(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: lbz 21, 135(1)
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: add 5, 23, 5
; PPC32-NEXT: lbz 23, 127(1)
; PPC32-NEXT: add 6, 22, 6
; PPC32-NEXT: lbz 22, 131(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: add 10, 21, 10
; PPC32-NEXT: stw 26, 40(1) # 4-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: add 8, 23, 8
; PPC32-NEXT: lbz 26, 83(1)
; PPC32-NEXT: add 9, 22, 9
; PPC32-NEXT: lbz 21, 147(1)
; PPC32-NEXT: stw 24, 32(1) # 4-byte Folded Spill
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: stw 25, 36(1) # 4-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: add 26, 21, 26
; PPC32-NEXT: lbz 25, 79(1)
; PPC32-NEXT: lbz 24, 75(1)
; PPC32-NEXT: lbz 23, 139(1)
; PPC32-NEXT: lbz 22, 143(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: stw 29, 52(1) # 4-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: add 24, 23, 24
; PPC32-NEXT: lbz 29, 95(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: add 25, 22, 25
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: lbz 21, 159(1)
; PPC32-NEXT: stw 27, 44(1) # 4-byte Folded Spill
; PPC32-NEXT: stw 28, 48(1) # 4-byte Folded Spill
; PPC32-NEXT: add 29, 21, 29
; PPC32-NEXT: lbz 28, 91(1)
; PPC32-NEXT: lbz 27, 87(1)
; PPC32-NEXT: lbz 23, 151(1)
; PPC32-NEXT: lbz 22, 155(1)
; PPC32-NEXT: lbz 4, 111(1)
; PPC32-NEXT: add 27, 23, 27
; PPC32-NEXT: lbz 21, 175(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: add 28, 22, 28
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: lbz 11, 107(1)
; PPC32-NEXT: lbz 12, 171(1)
; PPC32-NEXT: add 4, 21, 4
; PPC32-NEXT: stw 30, 56(1) # 4-byte Folded Spill
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: addi 4, 4, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: lbz 0, 103(1)
; PPC32-NEXT: add 11, 12, 11
; PPC32-NEXT: lbz 30, 99(1)
; PPC32-NEXT: lbz 23, 163(1)
; PPC32-NEXT: lbz 22, 167(1)
; PPC32-NEXT: add 30, 23, 30
; PPC32-NEXT: stb 4, 15(3)
; PPC32-NEXT: add 23, 22, 0
; PPC32-NEXT: addi 4, 11, 1
; PPC32-NEXT: stb 4, 14(3)
; PPC32-NEXT: addi 4, 23, 1
; PPC32-NEXT: stb 4, 13(3)
; PPC32-NEXT: addi 4, 30, 1
; PPC32-NEXT: stb 4, 12(3)
; PPC32-NEXT: addi 4, 29, 1
; PPC32-NEXT: stb 4, 11(3)
; PPC32-NEXT: addi 4, 28, 1
; PPC32-NEXT: stb 4, 10(3)
; PPC32-NEXT: addi 4, 27, 1
; PPC32-NEXT: stb 4, 9(3)
; PPC32-NEXT: addi 4, 26, 1
; PPC32-NEXT: stb 4, 8(3)
; PPC32-NEXT: addi 4, 25, 1
; PPC32-NEXT: stb 4, 7(3)
; PPC32-NEXT: addi 4, 24, 1
; PPC32-NEXT: stb 4, 6(3)
; PPC32-NEXT: addi 4, 10, 1
; PPC32-NEXT: stb 4, 5(3)
; PPC32-NEXT: addi 4, 9, 1
; PPC32-NEXT: stb 4, 4(3)
; PPC32-NEXT: addi 4, 8, 1
; PPC32-NEXT: stb 4, 3(3)
; PPC32-NEXT: addi 4, 7, 1
; PPC32-NEXT: stb 4, 2(3)
; PPC32-NEXT: addi 4, 6, 1
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: stb 4, 1(3)
; PPC32-NEXT: addi 4, 5, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC32-NEXT: stb 4, 0(3)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: lwz 30, 56(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 29, 52(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 28, 48(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 27, 44(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 26, 40(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 25, 36(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 24, 32(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 23, 28(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 22, 24(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 21, 20(1) # 4-byte Folded Reload
; PPC32-NEXT: addi 1, 1, 64
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC32-NEXT: blr
;
; PPC64BE-LABEL: vector_i128_i8:
; PPC64BE: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: std 21, -88(1) # 8-byte Folded Spill
; PPC64BE-NEXT: lbz 21, 207(1)
; PPC64BE-NEXT: std 22, -80(1) # 8-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: std 23, -72(1) # 8-byte Folded Spill
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC64BE-NEXT: std 25, -56(1) # 8-byte Folded Spill
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: std 24, -64(1) # 8-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: std 28, -32(1) # 8-byte Folded Spill
; PPC64BE-NEXT: std 27, -40(1) # 8-byte Folded Spill
; PPC64BE-NEXT: std 26, -48(1) # 8-byte Folded Spill
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: std 30, -16(1) # 8-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: std 29, -24(1) # 8-byte Folded Spill
; PPC64BE-NEXT: lbz 22, 199(1)
; PPC64BE-NEXT: lbz 23, 191(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: add 6, 21, 6
; PPC64BE-NEXT: lbz 21, 231(1)
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: add 5, 22, 5
; PPC64BE-NEXT: lbz 22, 223(1)
; PPC64BE-NEXT: add 4, 23, 4
; PPC64BE-NEXT: lbz 23, 215(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: add 9, 21, 9
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lbz 25, 127(1)
; PPC64BE-NEXT: add 8, 22, 8
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: lbz 21, 255(1)
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: add 7, 23, 7
; PPC64BE-NEXT: lbz 24, 119(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: addi 9, 9, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lbz 22, 247(1)
; PPC64BE-NEXT: add 25, 21, 25
; PPC64BE-NEXT: lbz 23, 239(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: addi 8, 8, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lbz 28, 151(1)
; PPC64BE-NEXT: add 24, 22, 24
; PPC64BE-NEXT: lbz 21, 279(1)
; PPC64BE-NEXT: add 10, 23, 10
; PPC64BE-NEXT: lbz 27, 143(1)
; PPC64BE-NEXT: addi 10, 10, 1
; PPC64BE-NEXT: lbz 22, 271(1)
; PPC64BE-NEXT: add 28, 21, 28
; PPC64BE-NEXT: lbz 26, 135(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: addi 7, 7, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lbz 23, 263(1)
; PPC64BE-NEXT: add 27, 22, 27
; PPC64BE-NEXT: lbz 11, 183(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: addi 6, 6, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lbz 21, 311(1)
; PPC64BE-NEXT: add 26, 23, 26
; PPC64BE-NEXT: lbz 12, 175(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: addi 5, 5, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lbz 0, 303(1)
; PPC64BE-NEXT: add 11, 21, 11
; PPC64BE-NEXT: lbz 30, 167(1)
; PPC64BE-NEXT: addi 11, 11, 1
; PPC64BE-NEXT: lbz 22, 295(1)
; PPC64BE-NEXT: add 12, 0, 12
; PPC64BE-NEXT: lbz 29, 159(1)
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: addi 4, 4, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lbz 23, 287(1)
; PPC64BE-NEXT: add 30, 22, 30
; PPC64BE-NEXT: stb 11, 15(3)
; PPC64BE-NEXT: addi 11, 12, 1
; PPC64BE-NEXT: add 29, 23, 29
; PPC64BE-NEXT: stb 11, 14(3)
; PPC64BE-NEXT: addi 11, 30, 1
; PPC64BE-NEXT: stb 11, 13(3)
; PPC64BE-NEXT: addi 11, 29, 1
; PPC64BE-NEXT: stb 11, 12(3)
; PPC64BE-NEXT: addi 11, 28, 1
; PPC64BE-NEXT: stb 11, 11(3)
; PPC64BE-NEXT: addi 11, 27, 1
; PPC64BE-NEXT: stb 11, 10(3)
; PPC64BE-NEXT: addi 11, 26, 1
; PPC64BE-NEXT: stb 11, 9(3)
; PPC64BE-NEXT: addi 11, 25, 1
; PPC64BE-NEXT: stb 11, 8(3)
; PPC64BE-NEXT: addi 11, 24, 1
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: stb 11, 7(3)
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC64BE-NEXT: stb 10, 6(3)
; PPC64BE-NEXT: stb 9, 5(3)
; PPC64BE-NEXT: stb 8, 4(3)
; PPC64BE-NEXT: stb 7, 3(3)
; PPC64BE-NEXT: stb 6, 2(3)
; PPC64BE-NEXT: stb 5, 1(3)
; PPC64BE-NEXT: stb 4, 0(3)
; PPC64BE-NEXT: ld 30, -16(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 29, -24(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 28, -32(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 27, -40(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 26, -48(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 25, -56(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 24, -64(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 23, -72(1) # 8-byte Folded Reload
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: ld 22, -80(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 21, -88(1) # 8-byte Folded Reload
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC64BE-NEXT: blr
;
; PPC64LE-LABEL: vector_i128_i8:
; PPC64LE: # %bb.0:
; PPC64LE-NEXT: xxlnor 34, 34, 34
; PPC64LE-NEXT: vsububm 2, 3, 2
; PPC64LE-NEXT: blr
%t0 = xor <16 x i8> %x, <i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1, i8 -1>
%t1 = sub <16 x i8> %y, %t0
ret <16 x i8> %t1
}
define <8 x i16> @vector_i128_i16(<8 x i16> %x, <8 x i16> %y) nounwind {
; PPC32-LABEL: vector_i128_i16:
; PPC32: # %bb.0:
; PPC32-NEXT: stwu 1, -32(1)
; PPC32-NEXT: stw 26, 8(1) # 4-byte Folded Spill
; PPC32-NEXT: stw 27, 12(1) # 4-byte Folded Spill
; PPC32-NEXT: stw 28, 16(1) # 4-byte Folded Spill
; PPC32-NEXT: stw 29, 20(1) # 4-byte Folded Spill
; PPC32-NEXT: stw 30, 24(1) # 4-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: lhz 11, 70(1)
; PPC32-NEXT: lhz 12, 66(1)
; PPC32-NEXT: lhz 0, 62(1)
; PPC32-NEXT: add 10, 11, 10
; PPC32-NEXT: lhz 30, 58(1)
; PPC32-NEXT: add 9, 12, 9
; PPC32-NEXT: lhz 29, 50(1)
; PPC32-NEXT: add 8, 0, 8
; PPC32-NEXT: lhz 28, 42(1)
; PPC32-NEXT: add 7, 30, 7
; PPC32-NEXT: lhz 27, 46(1)
; PPC32-NEXT: add 5, 29, 5
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: lhz 26, 54(1)
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: add 3, 28, 3
; PPC32-NEXT: add 4, 27, 4
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: addi 3, 3, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC32-NEXT: add 6, 26, 6
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: addi 4, 4, 1
; PPC32-NEXT: addi 5, 5, 1
; PPC32-NEXT: addi 6, 6, 1
; PPC32-NEXT: addi 7, 7, 1
; PPC32-NEXT: addi 8, 8, 1
; PPC32-NEXT: addi 9, 9, 1
; PPC32-NEXT: addi 10, 10, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC32-NEXT: lwz 30, 24(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 29, 20(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 28, 16(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 27, 12(1) # 4-byte Folded Reload
; PPC32-NEXT: lwz 26, 8(1) # 4-byte Folded Reload
; PPC32-NEXT: addi 1, 1, 32
; PPC32-NEXT: blr
;
; PPC64BE-LABEL: vector_i128_i16:
; PPC64BE: # %bb.0:
; PPC64BE-NEXT: std 25, -56(1) # 8-byte Folded Spill
; PPC64BE-NEXT: std 26, -48(1) # 8-byte Folded Spill
; PPC64BE-NEXT: std 27, -40(1) # 8-byte Folded Spill
; PPC64BE-NEXT: std 28, -32(1) # 8-byte Folded Spill
; PPC64BE-NEXT: std 29, -24(1) # 8-byte Folded Spill
; PPC64BE-NEXT: std 30, -16(1) # 8-byte Folded Spill
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: lhz 11, 118(1)
; PPC64BE-NEXT: lhz 12, 182(1)
; PPC64BE-NEXT: lhz 0, 174(1)
; PPC64BE-NEXT: lhz 30, 166(1)
; PPC64BE-NEXT: add 11, 12, 11
; PPC64BE-NEXT: lhz 29, 158(1)
; PPC64BE-NEXT: add 10, 0, 10
; PPC64BE-NEXT: lhz 28, 142(1)
; PPC64BE-NEXT: add 9, 30, 9
; PPC64BE-NEXT: lhz 27, 126(1)
; PPC64BE-NEXT: add 8, 29, 8
; PPC64BE-NEXT: lhz 26, 134(1)
; PPC64BE-NEXT: add 6, 28, 6
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: lhz 25, 150(1)
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: add 4, 27, 4
; PPC64BE-NEXT: add 5, 26, 5
; PPC64BE-NEXT: addi 11, 11, 1
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: add 7, 25, 7
; PPC64BE-NEXT: addi 10, 10, 1
[MachineScheduler] Update available queue on the first mop of a new cycle If a resource can be held for multiple cycles in the schedule model then an instruction can be placed into the available queue, another instruction can be scheduled, but the first will not be taken back out if the two instructions hazard. To fix this make sure that we update the available queue even on the first MOp of a cycle, pushing available instructions back into the pending queue if they now conflict. This happens with some downstream schedules we have around MVE instruction scheduling where we use ResourceCycles=[2] to show the instruction executing over two beats. Apparently the test changes here are OK too. Differential Revision: https://reviews.llvm.org/D76909
2020-06-10 00:35:45 +08:00
; PPC64BE-NEXT: addi 9, 9, 1
; PPC64BE-NEXT: addi 8, 8, 1
; PPC64BE-NEXT: addi 7, 7, 1
; PPC64BE-NEXT: addi 6, 6, 1
; PPC64BE-NEXT: addi 5, 5, 1
; PPC64BE-NEXT: addi 4, 4, 1
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: sth 11, 14(3)
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC64BE-NEXT: sth 10, 12(3)
; PPC64BE-NEXT: sth 9, 10(3)
; PPC64BE-NEXT: sth 8, 8(3)
; PPC64BE-NEXT: sth 7, 6(3)
; PPC64BE-NEXT: sth 6, 4(3)
; PPC64BE-NEXT: sth 5, 2(3)
; PPC64BE-NEXT: sth 4, 0(3)
; PPC64BE-NEXT: ld 30, -16(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 29, -24(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 28, -32(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 27, -40(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 26, -48(1) # 8-byte Folded Reload
; PPC64BE-NEXT: ld 25, -56(1) # 8-byte Folded Reload
; PPC64BE-NEXT: blr
;
; PPC64LE-LABEL: vector_i128_i16:
; PPC64LE: # %bb.0:
; PPC64LE-NEXT: xxlnor 34, 34, 34
; PPC64LE-NEXT: vsubuhm 2, 3, 2
; PPC64LE-NEXT: blr
%t0 = xor <8 x i16> %x, <i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1, i16 -1>
%t1 = sub <8 x i16> %y, %t0
ret <8 x i16> %t1
}
define <4 x i32> @vector_i128_i32(<4 x i32> %x, <4 x i32> %y) nounwind {
; PPC32-LABEL: vector_i128_i32:
; PPC32: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC32-NEXT: add 3, 7, 3
; PPC32-NEXT: add 4, 8, 4
; PPC32-NEXT: add 5, 9, 5
; PPC32-NEXT: add 6, 10, 6
; PPC32-NEXT: addi 3, 3, 1
; PPC32-NEXT: addi 4, 4, 1
; PPC32-NEXT: addi 5, 5, 1
; PPC32-NEXT: addi 6, 6, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC32-NEXT: blr
;
; PPC64BE-LABEL: vector_i128_i32:
; PPC64BE: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: add 6, 10, 6
; PPC64BE-NEXT: add 5, 9, 5
; PPC64BE-NEXT: add 4, 8, 4
; PPC64BE-NEXT: add 3, 7, 3
; PPC64BE-NEXT: addi 6, 6, 1
; PPC64BE-NEXT: addi 5, 5, 1
; PPC64BE-NEXT: addi 4, 4, 1
; PPC64BE-NEXT: addi 3, 3, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC64BE-NEXT: blr
;
; PPC64LE-LABEL: vector_i128_i32:
; PPC64LE: # %bb.0:
; PPC64LE-NEXT: xxlnor 34, 34, 34
; PPC64LE-NEXT: vsubuwm 2, 3, 2
; PPC64LE-NEXT: blr
%t0 = xor <4 x i32> %x, <i32 -1, i32 -1, i32 -1, i32 -1>
%t1 = sub <4 x i32> %y, %t0
ret <4 x i32> %t1
}
define <2 x i64> @vector_i128_i64(<2 x i64> %x, <2 x i64> %y) nounwind {
; PPC32-LABEL: vector_i128_i64:
; PPC32: # %bb.0:
[PowerPC] Add some InstAlias definitions Summary: This patch add the InstAlias definitions for below instructions. ADDI ADDIS ADDI8 ADDIS8 RLWINM8 ISEL ISEL8 OR OR_rec ORI ORI8 XORI8 CNTLZW8 CNTLZW8_rec TEND TSR RFEBB NOR NOR_rec MTCRF SUBF SUBF_rec SUBFC SUBFC_rec RLDICL_32_64 TW Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77559
2020-05-24 22:05:28 +08:00
; PPC32-NEXT: not 4, 4
; PPC32-NEXT: not 3, 3
; PPC32-NEXT: subc 4, 8, 4
; PPC32-NEXT: not 6, 6
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC32-NEXT: subfe 3, 3, 7
[PowerPC] Add some InstAlias definitions Summary: This patch add the InstAlias definitions for below instructions. ADDI ADDIS ADDI8 ADDIS8 RLWINM8 ISEL ISEL8 OR OR_rec ORI ORI8 XORI8 CNTLZW8 CNTLZW8_rec TEND TSR RFEBB NOR NOR_rec MTCRF SUBF SUBF_rec SUBFC SUBFC_rec RLDICL_32_64 TW Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77559
2020-05-24 22:05:28 +08:00
; PPC32-NEXT: not 5, 5
; PPC32-NEXT: subc 6, 10, 6
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC32-NEXT: subfe 5, 5, 9
; PPC32-NEXT: blr
;
; PPC64BE-LABEL: vector_i128_i64:
; PPC64BE: # %bb.0:
[Codegen][X86][AArch64][ARM][PowerPC] Inc-of-add vs sub-of-not (PR42457) Summary: This is the backend part of [[ https://bugs.llvm.org/show_bug.cgi?id=42457 | PR42457 ]]. In middle-end, we'd want to prefer the form with two adds - D63992, but as this diff shows, not every target will prefer that pattern. Out of 4 targets for which i added tests all seem to be ok with inc-of-add for scalars, but only X86 prefer that same pattern for vectors. Here i'm adding a new TLI hook, always defaulting to the inc-of-add, but adding AArch64,ARM,PowerPC overrides to prefer inc-of-add only for scalars. Reviewers: spatel, RKSimon, efriedma, t.p.northover, hfinkel Reviewed By: efriedma Subscribers: nemanjai, javed.absar, kristof.beyls, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64090 llvm-svn: 365010
2019-07-03 17:41:35 +08:00
; PPC64BE-NEXT: add 3, 5, 3
; PPC64BE-NEXT: add 4, 6, 4
; PPC64BE-NEXT: addi 3, 3, 1
; PPC64BE-NEXT: addi 4, 4, 1
[NFC][Codegen][X86][AArch64][ARM][PowerPC] Recommit: Add test coverage for "add-of-inc" vs "sub-of-not" I initially committed it with --check-prefix instead of --check-prefixes (again, shame on me, and utils/update_*.py not complaining!) and did not have a moment to understand the failure, so i reverted it initially in rL64939. llvm-svn: 364945
2019-07-03 00:48:49 +08:00
; PPC64BE-NEXT: blr
;
; PPC64LE-LABEL: vector_i128_i64:
; PPC64LE: # %bb.0:
; PPC64LE-NEXT: xxlnor 34, 34, 34
; PPC64LE-NEXT: vsubudm 2, 3, 2
; PPC64LE-NEXT: blr
%t0 = xor <2 x i64> %x, <i64 -1, i64 -1>
%t1 = sub <2 x i64> %y, %t0
ret <2 x i64> %t1
}