llvm-project.git/llvm/test/CodeGen/VE/Vector, branch users/nico/python-2 Unnamed repository; edit this file 'description' to name the repository. Reland [SelectionDAG] Folding ZERO-EXTEND/SIGN_EXTEND poison to Poison value in getNode (#136701) 2025-04-22T21:36:41+00:00 zhijian lin zhijian@ca.ibm.com 2025-04-22T21:36:41+00:00 afda4c295b1f8c4c4011358eddc1a08e17cd5b4d This patch addresses the signed/zero extension of poison by using a poison value of the extended type instead of a constant zero of the extended type. 
This patch addresses the signed/zero extension of poison by using a
poison value of the extended type instead of a constant zero of the
extended type.
 [VE,test] Change llc -march= to -mtriple= 2024-12-15T18:24:14+00:00 Fangrui Song i@maskray.me 2024-12-15T18:24:14+00:00 5240e0b891fc4bf69d362199f70c94c28a7b9465 Similar to 806761a7629df268c8aed49657aeccffa6bca449 -mtriple= specifies the full target triple while -march= merely sets the architecture part of the default target triple, leaving a target triple which may not make sense. Therefore, -march= is error-prone and not recommended for tests without a target triple. The issue has been benign as we recognize $ve-apple-darwin as ELF instead of rejecting it outrightly. 
Similar to 806761a7629df268c8aed49657aeccffa6bca449

-mtriple= specifies the full target triple while -march= merely sets the
architecture part of the default target triple, leaving a target triple which
may not make sense.

Therefore, -march= is error-prone and not recommended for tests without a target
triple. The issue has been benign as we recognize $ve-apple-darwin as ELF instead
of rejecting it outrightly.
[VE] Change the way of lowering store 2023-08-18T08:13:55+00:00 Kazushi (Jam) Marukawa marukawa@nec.com 2023-08-15T05:21:41+00:00 2e2395651e4327eec820424f9d647b856745aeb4 Change lowering store iff the data operand is leagalized. In this way, llvm can lower only operands first, then lower store instruction later. Reviewed By: efocht Differential Revision: https://reviews.llvm.org/D158253 
Change lowering store iff the data operand is leagalized.  In this way,
llvm can lower only operands first, then lower store instruction later.

Reviewed By: efocht

Differential Revision: https://reviews.llvm.org/D158253
[VE] Avoid vectorizing store/load in scalar mode 2023-08-16T17:15:54+00:00 Kazushi (Jam) Marukawa marukawa@nec.com 2023-08-15T04:52:12+00:00 922ac64b04b12f70135a53460610326ba2b72283 Avoid vectorizing store and load instructions in scalar mode. Reviewed By: efocht Differential Revision: https://reviews.llvm.org/D158049 
Avoid vectorizing store and load instructions in scalar mode.

Reviewed By: efocht

Differential Revision: https://reviews.llvm.org/D158049
[DAGCombiner][AArch64][VE] Teach BuildUDIV/SDIV to use 2x mul when mulh/mul_lohi are not available. 2023-05-12T16:06:17+00:00 Craig Topper craig.topper@sifive.com 2023-05-12T16:06:07+00:00 a983ef2c1743d8c8240b83ab307d7adcbaa73693 Correct the legality of i32 mul_lohi on AArch64. Previously, AArch64 incorrectly reported i32 mul_lohi as Legal. This allowed BuildUDIV/SDIV to use them. A later DAGCombiner would replace them with MULHS/MULHU because only the high half was used. This conversion does not check the legality of MULHS/MULHU under the assumption that LegalizeDAG can turn it back into MUL_LOHI later. After they are converted to MULHS/MULHU, DAGCombine ran and saw that these operations aren't supported but an i64 MUL is. So they get converted to that plus a shift. Without this, LegalizeDAG would convert back MUL_LOHI and isel would fail to find a pattern. This patch teaches BuildUDIV/SDIV to create the wide mul and shift so that we can report the correct operation legality on AArch64. It also enables div by constant folding for more cases on VE. I don't know if VE wants this div by constant optimization or not. If they don't want it, they can use the isIntDivCheap hook to disable it. Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D150333 
Correct the legality of i32 mul_lohi on AArch64.

Previously, AArch64 incorrectly reported i32 mul_lohi as Legal.
This allowed BuildUDIV/SDIV to use them. A later DAGCombiner would
replace them with MULHS/MULHU because only the high half was used.
This conversion does not check the legality of MULHS/MULHU under
the assumption that LegalizeDAG can turn it back into MUL_LOHI later.

After they are converted to MULHS/MULHU, DAGCombine ran and saw that
these operations aren't supported but an i64 MUL is. So they get
converted to that plus a shift. Without this, LegalizeDAG would
convert back MUL_LOHI and isel would fail to find a pattern.

This patch teaches BuildUDIV/SDIV to create the wide mul and shift
so that we can report the correct operation legality on AArch64. It
also enables div by constant folding for more cases on VE.

I don't know if VE wants this div by constant optimization or not. If they
don't want it, they can use the isIntDivCheap hook to disable it.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D150333
[VE] Convert some tests to opaque pointers (NFC) 2022-12-19T12:06:34+00:00 Nikita Popov npopov@redhat.com 2022-12-19T12:06:08+00:00 b006b60dc993b2e0ba3e412c80709477241b6be6 






[SDAG] avoid udiv/urem transform for vector/scalar type mismatches
2022-11-15T16:01:18+00:00

Sanjay Patel
spatel@rotateright.com

2022-11-15T15:43:51+00:00

fe05a0a3ddbf7fb54af9536331d39b138763e17a

This solves the crashing from issue #58994.
I don't know anything about VE, so I don't know if the output
is as expected or even correct.





This solves the crashing from issue #58994.
I don't know anything about VE, so I don't know if the output
is as expected or even correct.







[CodeGen] Using ZExt for extractelement indices.
2022-10-15T22:45:35+00:00

Peter Rong
PeterRong96@gmail.com

2022-08-30T21:55:59+00:00

c2e7c9cb33acbd118fe5011a1607d6cf8e21de34

In https://github.com/llvm/llvm-project/issues/57452, we found that IRTranslator is translating `i1 true` into `i32 -1`.
This is because IRTranslator uses SExt for indices.

In this fix, we change the expected behavior of extractelement's index, moving from SExt to ZExt.
This change includes both documentation, SelectionDAG and IRTranslator.
We also included a test for AMDGPU, updated tests for AArch64, Mips, PowerPC, RISCV, VE, WebAssembly and X86

This patch fixes issue #57452.

Differential Revision: https://reviews.llvm.org/D132978





In https://github.com/llvm/llvm-project/issues/57452, we found that IRTranslator is translating `i1 true` into `i32 -1`.
This is because IRTranslator uses SExt for indices.

In this fix, we change the expected behavior of extractelement's index, moving from SExt to ZExt.
This change includes both documentation, SelectionDAG and IRTranslator.
We also included a test for AMDGPU, updated tests for AArch64, Mips, PowerPC, RISCV, VE, WebAssembly and X86

This patch fixes issue #57452.

Differential Revision: https://reviews.llvm.org/D132978







[VP][VE] Default VP_SREM/UREM to Expand and add generic expansion using VP_SDIV/UDIV+VP_MUL+VP_SUB.
2022-09-16T20:19:02+00:00

Craig Topper
craig.topper@sifive.com

2022-09-16T19:59:13+00:00

1121eca685a39c1fc370daa65ff918a3cd490dc4

I want to default all VP operations to Expand. These 2 were blocking
because VE doesn't support them and the tests were expecting them
to fail a specific way. Using Expand caused them to fail differently.

Seemed better to emulate them using operations that are supported.

@simoll mentioned on Discord that VE has some expansion downstream. Not
sure if its done like this or in the VE target.

Reviewed By: frasercrmck, efocht

Differential Revision: https://reviews.llvm.org/D133514





I want to default all VP operations to Expand. These 2 were blocking
because VE doesn't support them and the tests were expecting them
to fail a specific way. Using Expand caused them to fail differently.

Seemed better to emulate them using operations that are supported.

@simoll mentioned on Discord that VE has some expansion downstream. Not
sure if its done like this or in the VE target.

Reviewed By: frasercrmck, efocht

Differential Revision: https://reviews.llvm.org/D133514







[VE] Support load/store/spill of vector mask registers
2022-07-19T01:29:21+00:00

Kazushi (Jam) Marukawa
marukawa@nec.com

2022-07-02T04:51:20+00:00

469044cfd355d34573643a57b5d2a78a9c341327

Support load/store/spill of vector mask registers and add regression
tests.

Reviewed By: efocht

Differential Revision: https://reviews.llvm.org/D129415





Support load/store/spill of vector mask registers and add regression
tests.

Reviewed By: efocht

Differential Revision: https://reviews.llvm.org/D129415