History log of /llvm-project-15.0.7/llvm/lib/Target/PowerPC/PPCInstrAltivec.td (Results 1 – 25 of 177)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345678