|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
c933c2eb |
| 23-Nov-2021 |
Nemanja Ivanovic <[email protected]> |
[PowerPC] Add BCD add/sub/cmp builtins
Support for builtins that use bcdadd./bcdsub. to add/subtract Binary Coded Decimal values as well as to determine validity and compare BCD values.
Differentia
[PowerPC] Add BCD add/sub/cmp builtins
Support for builtins that use bcdadd./bcdsub. to add/subtract Binary Coded Decimal values as well as to determine validity and compare BCD values.
Differential revision: https://reviews.llvm.org/D114088
show more ...
|
| #
09b67aa1 |
| 29-Sep-2021 |
Nemanja Ivanovic <[email protected]> |
[PowerPC] Implement builtin for vbpermd
The instruction has similar semantics to vbpermq but for doublewords. It was added in Power9 and the ABI documents the builtin.
Differential revision: https:
[PowerPC] Implement builtin for vbpermd
The instruction has similar semantics to vbpermq but for doublewords. It was added in Power9 and the ABI documents the builtin.
Differential revision: https://reviews.llvm.org/D107899
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
511f4ae5 |
| 17-May-2021 |
Nemanja Ivanovic <[email protected]> |
[PowerPC] Add patterns for vselect of v1i128
These patterns are missing even though the underlying instruction doesn't really care about the type. Added these patterns to resolve https://bugs.llvm.o
[PowerPC] Add patterns for vselect of v1i128
These patterns are missing even though the underlying instruction doesn't really care about the type. Added these patterns to resolve https://bugs.llvm.org/show_bug.cgi?id=50084
show more ...
|
| #
74ae7781 |
| 17-May-2021 |
Nemanja Ivanovic <[email protected]> |
[PowerPC] Do not emit dssall on AIX
This instruction is a nop on all server cores (certainly on all cores that AIX supports) so it is fine to emit a nop instead of it. In fact, that is exactly what
[PowerPC] Do not emit dssall on AIX
This instruction is a nop on all server cores (certainly on all cores that AIX supports) so it is fine to emit a nop instead of it. In fact, that is exactly what XL emits. So we emit a nop on AIX and we leave the codegen as is on other platforms since there may indeed be cores out there for which this actually does some prefetching.
show more ...
|
| #
64d951be |
| 28-Apr-2021 |
Amy Kwan <[email protected]> |
[PowerPC] Add new infrastructure to select load/store instructions, update P8/P9 load/store patterns.
This patch introduces a new infrastructure that is used to select the load and store instruction
[PowerPC] Add new infrastructure to select load/store instructions, update P8/P9 load/store patterns.
This patch introduces a new infrastructure that is used to select the load and store instructions in the PPC backend.
The primary motivation is that the current implementation of selecting load/stores is dependent on the ordering of patterns in TableGen. Given this limitation, we are not able to easily and reliably generate the P10 prefixed load and stores instructions (such as when the immediates that fit within 34-bits). This refactoring is meant to provide us with more control over the patterns/different forms to exploit, as well as eliminating dependency of pattern declaration in TableGen.
The idea of this refactoring is that it introduces a set of addressing modes that correspond to different instruction formats of a particular load and store instruction, along with a set of common flags that describes a load/store. Whenever a load/store instruction is being selected, we analyze the instruction and compute a set of flags for it. The computed flags are then used to select the most optimal load/store addressing mode.
This patch is the first of a series of patches to be committed - it contains the initial implementation of the refactored load/store selection infrastructure and also updates P8/P9 patterns to adopt this infrastructure. The idea is that incremental patches will add more implementation and support, and eventually the old implementation will be removed.
Differential Revision: https://reviews.llvm.org/D93370
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3 |
|
| #
94206f1f |
| 01-Feb-2021 |
Craig Topper <[email protected]> |
[PowerPC] Remove vnot_ppc and replace with the standard vnot.
immAllOnesV has special support for looking through bitcasts automatically so isel patterns don't need to explicitly look for the bitcon
[PowerPC] Remove vnot_ppc and replace with the standard vnot.
immAllOnesV has special support for looking through bitcasts automatically so isel patterns don't need to explicitly look for the bitconvert.
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init |
|
| #
1150bfa6 |
| 25-Jan-2021 |
Nemanja Ivanovic <[email protected]> |
[PowerPC] Add missing negate for VPERMXOR on little endian subtargets
This intrinsic is supposed to have the permute control vector complemented on little endian systems (as the ABI specifies and GC
[PowerPC] Add missing negate for VPERMXOR on little endian subtargets
This intrinsic is supposed to have the permute control vector complemented on little endian systems (as the ABI specifies and GCC implements). With the current code gen, the result vector is byte-reversed.
Differential revision: https://reviews.llvm.org/D95004
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
56406652 |
| 05-Nov-2020 |
Chen Zheng <[email protected]> |
[PowerPC] add has side effect for SAT bit clobber intrinsics/instructions
This patch does two things: 1: fix the typo that intrinsic mfvscr should be with no readmem property 2: since VSCR is not mo
[PowerPC] add has side effect for SAT bit clobber intrinsics/instructions
This patch does two things: 1: fix the typo that intrinsic mfvscr should be with no readmem property 2: since VSCR is not modeled yet, add has side effect for SAT bit clobber intrinsics/instructions.
Reviewed By: steven.zhang
Differential Revision: https://reviews.llvm.org/D90807
show more ...
|
| #
fa42f08b |
| 25-Nov-2020 |
QingShan Zhang <[email protected]> |
[PowerPC][FP128] Fix the incorrect calling convention for IEEE long double on Power8
For now, we are using the GPR to pass the arguments/return value for fp128 on Power8, which is incorrect. It shou
[PowerPC][FP128] Fix the incorrect calling convention for IEEE long double on Power8
For now, we are using the GPR to pass the arguments/return value for fp128 on Power8, which is incorrect. It should be VSR. The reason why we do it this way is that, we are setting the fp128 as illegal which make LLVM try to emulate it with i128 on Power8. So, we need to correct it as legal.
Reviewed By: Nemanjai
Differential Revision: https://reviews.llvm.org/D91527
show more ...
|
| #
3204ffea |
| 03-Nov-2020 |
Qiu Chaofan <[email protected]> |
[PowerPC] [NFC] Rename VCMPo to VCMP_rec
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D90581
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4 |
|
| #
d7eb917a |
| 23-Sep-2020 |
Albion Fung <[email protected]> |
[PowerPC] Implementation of 128-bit Binary Vector Mod and Sign Extend builtins
This patch implements 128-bit Binary Vector Mod and Sign Extend builtins for PowerPC10.
Differential: https://reviews.
[PowerPC] Implementation of 128-bit Binary Vector Mod and Sign Extend builtins
This patch implements 128-bit Binary Vector Mod and Sign Extend builtins for PowerPC10.
Differential: https://reviews.llvm.org/D87394#inline-815858
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
5ca75130 |
| 09-Jun-2020 |
Kit Barton <[email protected]> |
[PPC][NFC] Add Subtarget and replace all uses of PPCSubTarget with Subtarget.
Summary: In preparation for GlobalISel, PPCSubTarget needs to be renamed to Subtarget as there places in GlobalISel that
[PPC][NFC] Add Subtarget and replace all uses of PPCSubTarget with Subtarget.
Summary: In preparation for GlobalISel, PPCSubTarget needs to be renamed to Subtarget as there places in GlobalISel that assume the presence of the variable Subtarget. This patch introduces the variable Subtarget, and replaces all existing uses of PPCSubTarget with Subtarget. A subsequent patch will remove the definiton of PPCSubTarget, once any downstream users have the opportunity to rename any uses they have.
Reviewers: hfinkel, nemanjai, jhibbits, #powerpc, echristo, lkail
Reviewed By: #powerpc, echristo, lkail
Subscribers: echristo, lkail, wuzish, nemanjai, hiraditya, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81623
show more ...
|
| #
7315d221 |
| 14-Jun-2020 |
Qiu Chaofan <[email protected]> |
[PowerPC] Exploit vnmsubfp instruction
On PowerPC, we have vnmsubfp Altivec instruction for fnmsub operation on v4f32 type. Default pattern for this instruction never works since we don't have legal
[PowerPC] Exploit vnmsubfp instruction
On PowerPC, we have vnmsubfp Altivec instruction for fnmsub operation on v4f32 type. Default pattern for this instruction never works since we don't have legal fneg for v4f32 when VSX disabled.
Reviewed By: steven.zhang
Differential Revision: https://reviews.llvm.org/D80617
show more ...
|
| #
a462561c |
| 03-Jun-2020 |
QingShan Zhang <[email protected]> |
[NFC][PowerPC] Remove unused node PPCISD::VMADDFP and PPCISD::VNMSUBFP
These two nodes were added by 69caef2b781130a7d0eeaf8898eb346b6423ae03 in 2005 and they are not used by PowerPC backend anymore
[NFC][PowerPC] Remove unused node PPCISD::VMADDFP and PPCISD::VNMSUBFP
These two nodes were added by 69caef2b781130a7d0eeaf8898eb346b6423ae03 in 2005 and they are not used by PowerPC backend anymore. And the ISD::FMA is a prefer way for VMADDFP if we really want to create that node. For VNMSUBFP, we will also add a more generic node FNMSUB in D76585 if we really want it.
Reviewed By: qiucf
Differential Revision: https://reviews.llvm.org/D80429
show more ...
|
| #
a28e9f12 |
| 22-May-2020 |
Ahsan Saghir <[email protected]> |
[PowerPC] Add support for vmsumudm
This patch adds support for Vector Multiply-Sum Unsigned Doubleword Modulo instruction; vmsumudm.
Differential Revision: https://reviews.llvm.org/D80294
|
|
Revision tags: llvmorg-10.0.1-rc1 |
|
| #
1ef7bf41 |
| 26-Mar-2020 |
QingShan Zhang <[email protected]> |
[PowerPC] Improve the way legalize mul for v8i16 and add pattern to match mul + add
We can legalize the operation MUL for v8i16 with instruction (vmladduhm A, B, 0) if altivec enabled. Now, it is se
[PowerPC] Improve the way legalize mul for v8i16 and add pattern to match mul + add
We can legalize the operation MUL for v8i16 with instruction (vmladduhm A, B, 0) if altivec enabled. Now, it is set as custom and expand it later, which is not the right way. And then, we can add the pattern to match the mul + add with (vmladduhm A, B, C)
Reviewed By: Nemanjai
Differential Revision: https://reviews.llvm.org/D76751
show more ...
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
9c64f04d |
| 15-Jan-2020 |
Nemanja Ivanovic <[email protected]> |
[PowerPC] Legalize saturating vector add/sub
These intrinsics and the corresponding ISD nodes were recently added. PPC has instructions that do this for vectors. Legalize them and add patterns to em
[PowerPC] Legalize saturating vector add/sub
These intrinsics and the corresponding ISD nodes were recently added. PPC has instructions that do this for vectors. Legalize them and add patterns to emit the satuarting instructions.
Differential revision: https://reviews.llvm.org/D71940
show more ...
|
|
Revision tags: llvmorg-11-init |
|
| #
24ee4ede |
| 06-Jan-2020 |
Jinsong Ji <[email protected]> |
[PowerPC][NFC] Rename record instructions to use _rec suffix instead of o
We use o suffix to indicate record form instuctions, (as it is similar to dot '.' in mne?)
This was fine before, as we did
[PowerPC][NFC] Rename record instructions to use _rec suffix instead of o
We use o suffix to indicate record form instuctions, (as it is similar to dot '.' in mne?)
This was fine before, as we did not support XO-form. However, with https://reviews.llvm.org/D66902, we now have XO-form support.
It becomes confusing now to still use 'o' for record form, and it is weird to have something like 'Oo' .
This patch rename all 'o' instructions to use '_rec' instead. Also rename `isDot` to `isRecordForm`.
Reviewed By: #powerpc, hfinkel, nemanjai, steven.zhang, lkail
Differential Revision: https://reviews.llvm.org/D70758
show more ...
|
| #
d1b51c5d |
| 28-Dec-2019 |
Kang Zhang <[email protected]> |
[PowerPC] Modify the hasSideEffects of some VSX instructions from 1 to 0
Summary: If we didn't set the value for hasSideEffects bit in our td file, `llvm-tblgen` will set it as true for those instr
[PowerPC] Modify the hasSideEffects of some VSX instructions from 1 to 0
Summary: If we didn't set the value for hasSideEffects bit in our td file, `llvm-tblgen` will set it as true for those instructions which has no match pattern. Below 6 instructions don't set the hasSideEffects flag and don't have match pattern, so their hasSideEffects flag will be set true by llvm-tblgen.
But in fact below instructions don't modify any special register and don't have other SideEffects, they shouldn't have SideEffects. This patch is to modify the hasSideEffects of below instructions from 1 to 0.
``` VEXTUHLX VEXTUHRX VEXTUWLX VEXTUWRX VSPLTBs VSPLTHs ```
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D71391
show more ...
|
| #
9681dc96 |
| 23-Dec-2019 |
Kai Luo <[email protected]> |
[PowerPC] Exploit `vrl(b|h|w|d)` to perform vector rotation
Summary: Currently, we set legalization action of `ISD::ROTL` vectors as `Expand` in `PPCISelLowering`. However, we can exploit `vrl(b|h|w
[PowerPC] Exploit `vrl(b|h|w|d)` to perform vector rotation
Summary: Currently, we set legalization action of `ISD::ROTL` vectors as `Expand` in `PPCISelLowering`. However, we can exploit `vrl(b|h|w|d)` to lower `ISD::ROTL` directly.
Differential Revision: https://reviews.llvm.org/D71324
show more ...
|
| #
7e0fd776 |
| 16-Dec-2019 |
Jim Lin <[email protected]> |
[PowerPC] Fix %llvm.ppc.altivec.vc* lowering
Summary: r372285 changed LLVM to use a `TargetConstant` for parameters of intrinsics that are required to be immediates.
Since that commit, use of `%llv
[PowerPC] Fix %llvm.ppc.altivec.vc* lowering
Summary: r372285 changed LLVM to use a `TargetConstant` for parameters of intrinsics that are required to be immediates.
Since that commit, use of `%llvm.ppc.altivec.vc{fsx,fux,tsxs,tuxs}` intrinsics has not worked, and resulted in a `LLVM ERROR: Cannot select: intrinsic %llvm.ppc.altivec.vc*` error. The intrinsics' TableGen definitions matched on `imm` instead of `timm`.
This commit updates those definitions to use `timm`.
Fixes: https://llvm.org/PR44239
Reviewers: hfinkel, nemanjai, #powerpc, Jim
Reviewed By: Jim
Subscribers: qiucf, wuzish, Jim, hiraditya, kbarton, jsji, shchenz, llvm-commits
Tags: #llvm
Patched by vddvss (Colin Samples).
Differential Revision: https://reviews.llvm.org/D71138
show more ...
|
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3 |
|
| #
f9929717 |
| 11-Dec-2019 |
QingShan Zhang <[email protected]> |
[PowerPC] Exploitate the Vector Integer Average Instructions
PowerPC has instruction to do the semantics of this piece of code:
vector int foo(vector int m, vector int n) { return (m + n + 1) >>
[PowerPC] Exploitate the Vector Integer Average Instructions
PowerPC has instruction to do the semantics of this piece of code:
vector int foo(vector int m, vector int n) { return (m + n + 1) >> 1; } This patch is adding the match rule to select it.
Differential Revision: https://reviews.llvm.org/D71002
show more ...
|
|
Revision tags: llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
a4cc895a |
| 22-Nov-2019 |
QingShan Zhang <[email protected]> |
[PowerPC] Implement the vector extend sign instruction pattern match Power9 has instructions to implement the semantics of SIGN_EXTEND_INREG for vector type. Mark it as legal and add the match patter
[PowerPC] Implement the vector extend sign instruction pattern match Power9 has instructions to implement the semantics of SIGN_EXTEND_INREG for vector type. Mark it as legal and add the match pattern.
Differential Revision: https://reviews.llvm.org/D69601
show more ...
|
| #
3ecab8e4 |
| 19-Sep-2019 |
Matt Arsenault <[email protected]> |
Reapply r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"
This reverts r372314, reapplying r372285 and the commits which depend on it (r372286-r372293, and r372296-r372297)
Thi
Reapply r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"
This reverts r372314, reapplying r372285 and the commits which depend on it (r372286-r372293, and r372296-r372297)
This was missing one switch to getTargetConstant in an untested case.
llvm-svn: 372338
show more ...
|
| #
13bdae85 |
| 19-Sep-2019 |
Hans Wennborg <[email protected]> |
Revert r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"
This broke the Chromium build, causing it to fail with e.g.
fatal error: error in backend: Cannot select: t362: v4i32
Revert r372285 "GlobalISel: Don't materialize immarg arguments to intrinsics"
This broke the Chromium build, causing it to fail with e.g.
fatal error: error in backend: Cannot select: t362: v4i32 = X86ISD::VSHLI t392, Constant:i8<15>
See llvm-commits thread of r372285 for details.
This also reverts r372286, r372287, r372288, r372289, r372290, r372291, r372292, r372293, r372296, and r372297, which seemed to depend on the main commit.
> Encode them directly as an imm argument to G_INTRINSIC*. > > Since now intrinsics can now define what parameters are required to be > immediates, avoid using registers for them. Intrinsics could > potentially want a constant that isn't a legal register type. Also, > since G_CONSTANT is subject to CSE and legalization, transforms could > potentially obscure the value (and create extra work for the > selector). The register bank of a G_CONSTANT is also meaningful, so > this could throw off future folding and legalization logic for AMDGPU. > > This will be much more convenient to work with than needing to call > getConstantVRegVal and checking if it may have failed for every > constant intrinsic parameter. AMDGPU has quite a lot of intrinsics wth > immarg operands, many of which need inspection during lowering. Having > to find the value in a register is going to add a lot of boilerplate > and waste compile time. > > SelectionDAG has always provided TargetConstant for constants which > should not be legalized or materialized in a register. The distinction > between Constant and TargetConstant was somewhat fuzzy, and there was > no automatic way to force usage of TargetConstant for certain > intrinsic parameters. They were both ultimately ConstantSDNode, and it > was inconsistently used. It was quite easy to mis-select an > instruction requiring an immediate. For SelectionDAG, start emitting > TargetConstant for these arguments, and using timm to match them. > > Most of the work here is to cleanup target handling of constants. Some > targets process intrinsics through intermediate custom nodes, which > need to preserve TargetConstant usage to match the intrinsic > expectation. Pattern inputs now need to distinguish whether a constant > is merely compatible with an operand or whether it is mandatory. > > The GlobalISelEmitter needs to treat timm as a special case of a leaf > node, simlar to MachineBasicBlock operands. This should also enable > handling of patterns for some G_* instructions with immediates, like > G_FENCE or G_EXTRACT. > > This does include a workaround for a crash in GlobalISelEmitter when > ARM tries to uses "imm" in an output with a "timm" pattern source.
llvm-svn: 372314
show more ...
|