Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
206ee719 |
| 17-Nov-2024 |
Brandon Wu <brandon.wu@sifive.com> |
[RISCV] Change vector tuple type's TypeSize to scalable (#114329)
Vector tuple is basically multiple grouped vector, so its size is also
determined by vscale, we need not to model it as a vector ty
[RISCV] Change vector tuple type's TypeSize to scalable (#114329)
Vector tuple is basically multiple grouped vector, so its size is also
determined by vscale, we need not to model it as a vector type but its
size need to be scalable.
show more ...
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
dc03ee3c |
| 31-Aug-2024 |
Brandon Wu <brandon.wu@sifive.com> |
[llvm][RISCV] Add RISCV vector tuple type to value types(MVT) (#97993)
Summary:
This patch handles the types(MVT) in `selectionDAG` for RISCV vector
tuples.
As described in previous patch handlin
[llvm][RISCV] Add RISCV vector tuple type to value types(MVT) (#97993)
Summary:
This patch handles the types(MVT) in `selectionDAG` for RISCV vector
tuples.
As described in previous patch handling llvm types, the MVTs also have
32 variants:
```
riscv_nxv1i8x2, riscv_nxv1i8x3, riscv_nxv1i8x4, riscv_nxv1i8x5, riscv_nxv1i8x6, riscv_nxv1i8x7, riscv_nxv1i8x8,
riscv_nxv2i8x2, riscv_nxv2i8x3, riscv_nxv2i8x4, riscv_nxv2i8x5, riscv_nxv2i8x6, riscv_nxv2i8x7, riscv_nxv2i8x8,
riscv_nxv4i8x2, riscv_nxv4i8x3, riscv_nxv4i8x4, riscv_nxv4i8x5, riscv_nxv4i8x6, riscv_nxv4i8x7, riscv_nxv4i8x8,
riscv_nxv8i8x2, riscv_nxv8i8x3, riscv_nxv8i8x4, riscv_nxv8i8x5, riscv_nxv8i8x6, riscv_nxv8i8x7, riscv_nxv8i8x8,
riscv_nxv16i8x2, riscv_nxv16i8x3, riscv_nxv16i8x4,
riscv_nxv32i8x2.
```
Detail:
An intuitive way to model vector tuple type is using nested scalable
vector, e.g. `nElts=NF, EltTy=nxv2i32`. However it's not compatible to
what we've done to handle scalable vector in TargetLowering, so it would
need more effort to change the code to handle this concept.
Another approach is encoding the `MinNumElts` info in `sz` of `MVT`,
e.g.
`nElts=NF, sz=(NF*MinNumElts*8)`, this makes it much easier to handle
and
changes less code.
This patch adopts the latter approach.
Stacked on https://github.com/llvm/llvm-project/pull/97992
show more ...
|
Revision tags: llvmorg-19.1.0-rc3 |
|
#
ae466a61 |
| 13-Aug-2024 |
Craig Topper <craig.topper@sifive.com> |
[SelectionDAG] Add getFltSemantics to MVT and EVT. NFC
This will be used to replace SelectionDAG::EVTToAPFloatSemantics
A similar method exists in IR's Type class.
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1 |
|
#
dfeb3991 |
| 25-Jul-2024 |
James Y Knight <jyknight@google.com> |
Remove the `x86_mmx` IR type. (#98505)
It is now translated to `<1 x i64>`, which allows the removal of a bunch
of special casing.
This _incompatibly_ changes the ABI of any LLVM IR function wit
Remove the `x86_mmx` IR type. (#98505)
It is now translated to `<1 x i64>`, which allows the removal of a bunch
of special casing.
This _incompatibly_ changes the ABI of any LLVM IR function with
`x86_mmx` arguments or returns: instead of passing in mmx registers,
they will now be passed via integer registers. However, the real-world
incompatibility caused by this is expected to be minimal, because Clang
never uses the x86_mmx type -- it lowers `__m64` to either `<1 x i64>`
or `double`, depending on ABI.
This change does _not_ eliminate the SelectionDAG `MVT::x86mmx` type.
That type simply no longer corresponds to an IR type, and is used only
by MMX intrinsics and inline-asm operands.
Because SelectionDAGBuilder only knows how to generate the
operands/results of intrinsics based on the IR type, it thus now
generates the intrinsics with the type MVT::v1i64, instead of
MVT::x86mmx. We need to fix this before the DAG LegalizeTypes, and thus
have the X86 backend fix them up in DAGCombine. (This may be a
short-lived hack, if all the MMX intrinsics can be removed in upcoming
changes.)
Works towards issue #98272.
show more ...
|
Revision tags: llvmorg-20-init |
|
#
3cd3b216 |
| 27-Jun-2024 |
Kito Cheng <kito.cheng@sifive.com> |
[ValueTypes][NFC] Generate EVT::getTypeForEVT from GenVT.inc (#96608)
Most of MVT has simple mapping to the LLVM type, so it would be nice to
auto generate that from ValueTypes.td, that could reduc
[ValueTypes][NFC] Generate EVT::getTypeForEVT from GenVT.inc (#96608)
Most of MVT has simple mapping to the LLVM type, so it would be nice to
auto generate that from ValueTypes.td, that could reduce the effort when
we adding new MVT, especially new vector MVT with different size.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7 |
|
#
c179d50f |
| 28-May-2024 |
Heejin Ahn <aheejin@gmail.com> |
[WebAssembly] Add exnref type (#93586)
This adds (back) the exnref type restored in the new EH proposal adopted
in Oct 2023 CG meeting:
https://github.com/WebAssembly/exception-handling/blob/mai
[WebAssembly] Add exnref type (#93586)
This adds (back) the exnref type restored in the new EH proposal adopted
in Oct 2023 CG meeting:
https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md:x
show more ...
|
#
7c937df0 |
| 22-May-2024 |
Jessica Clarke <jrtc27@jrtc27.com> |
[CodeGen] Forbid passing a PointerType to MVT::getVT and EVT::getEVT (#92671)
There is the expectation throughout CodeGen that, for types representing
"real" values, the MVT or EVT is self-containe
[CodeGen] Forbid passing a PointerType to MVT::getVT and EVT::getEVT (#92671)
There is the expectation throughout CodeGen that, for types representing
"real" values, the MVT or EVT is self-contained. However, MVT::iPTR is
challenging, because it has no address space, and even if it did, there
often is no DataLayout immediately accessible to determine what actually
is the underlying type.
Historically it was documented as being TableGen-only, but that was lost
in 631bfdbee5b45eda9f99dff6a716d63c5698e4bd's conversion to using the
generated defines. Let's preserve that intent by not allowing it to
originate through accidental calls to get(E)VT with a PointerType. If
you need to support that, be sure to use something like TargetLowering's
getValueType, which takes a DataLayout and can map pointers to their
concrete MVTs. Whilst here, reintroduce documentation about these value
types being TableGen-only.
show more ...
|
Revision tags: llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
60822637 |
| 06-Mar-2024 |
Sameer Sahasrabuddhe <sameer.sahasrabuddhe@amd.com> |
Restore "Implement convergence control in MIR using SelectionDAG (#71785)"
This restores commit c7fdd8c11e54585dc9d15d63de9742067e0506b9. Previously reverted in f010b1bef4dda2c7082cbb41dbabf1f149cce
Restore "Implement convergence control in MIR using SelectionDAG (#71785)"
This restores commit c7fdd8c11e54585dc9d15d63de9742067e0506b9. Previously reverted in f010b1bef4dda2c7082cbb41dbabf1f149cce306.
LLVM function calls carry convergence control tokens as operand bundles, where the tokens themselves are produced by convergence control intrinsics. This patch implements convergence control tokens in MIR as follows:
1. Introduce target-independent ISD opcodes and MIR opcodes for convergence control intrinsics. 2. Model token values as untyped virtual registers in MIR.
The change also introduces an additional ISD opcode CONVERGENCECTRL_GLUE and a corresponding machine opcode with the same spelling. This glues the convergence control token to SDNodes that represent calls to intrinsics. The glued token is later translated to an implicit argument in the MIR.
The lowering of calls to user-defined functions is target-specific. On AMDGPU, the convergence control operand bundle at a non-intrinsic call is translated to an explicit argument to the SI_CALL_ISEL instruction. Post-selection adjustment converts this explicit argument to an implicit argument on the SI_CALL instruction.
show more ...
|
#
f010b1be |
| 04-Mar-2024 |
Mitch Phillips <mitchp@google.com> |
Revert "Restore "Implement convergence control in MIR using SelectionDAG (#71785)""
This reverts commit c7fdd8c11e54585dc9d15d63de9742067e0506b9.
Reason: Broke the sanitizer buildbots. See the comm
Revert "Restore "Implement convergence control in MIR using SelectionDAG (#71785)""
This reverts commit c7fdd8c11e54585dc9d15d63de9742067e0506b9.
Reason: Broke the sanitizer buildbots. See the comments at https://github.com/llvm/llvm-project/pull/71785 for more information.
show more ...
|
#
c7fdd8c1 |
| 04-Mar-2024 |
Sameer Sahasrabuddhe <sameer.sahasrabuddhe@amd.com> |
Restore "Implement convergence control in MIR using SelectionDAG (#71785)"
Original commit 79889734b940356ab3381423c93ae06f22e772c9. Perviously reverted in commit a2afcd5721869d1d03c8146bae3885b3385
Restore "Implement convergence control in MIR using SelectionDAG (#71785)"
Original commit 79889734b940356ab3381423c93ae06f22e772c9. Perviously reverted in commit a2afcd5721869d1d03c8146bae3885b3385ba15e.
LLVM function calls carry convergence control tokens as operand bundles, where the tokens themselves are produced by convergence control intrinsics. This patch implements convergence control tokens in MIR as follows:
1. Introduce target-independent ISD opcodes and MIR opcodes for convergence control intrinsics. 2. Model token values as untyped virtual registers in MIR.
The change also introduces an additional ISD opcode CONVERGENCECTRL_GLUE and a corresponding machine opcode with the same spelling. This glues the convergence control token to SDNodes that represent calls to intrinsics. The glued token is later translated to an implicit argument in the MIR.
The lowering of calls to user-defined functions is target-specific. On AMDGPU, the convergence control operand bundle at a non-intrinsic call is translated to an explicit argument to the SI_CALL_ISEL instruction. Post-selection adjustment converts this explicit argument to an implicit argument on the SI_CALL instruction.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4 |
|
#
969d7ecf |
| 26-Feb-2024 |
Francesco Petrogalli <francesco.petrogalli@apple.com> |
[llvm][CodeGen] Add ValueType v3i1. [NFCI] (#82338)
|
#
a2afcd57 |
| 21-Feb-2024 |
Sameer Sahasrabuddhe <sameer.sahasrabuddhe@amd.com> |
Revert "Implement convergence control in MIR using SelectionDAG (#71785)"
This reverts commit 79889734b940356ab3381423c93ae06f22e772c9.
Encountered multiple buildbot failures.
|
Revision tags: llvmorg-18.1.0-rc3 |
|
#
79889734 |
| 21-Feb-2024 |
Sameer Sahasrabuddhe <sameer.sahasrabuddhe@amd.com> |
Implement convergence control in MIR using SelectionDAG (#71785)
LLVM function calls carry convergence control tokens as operand bundles, where
the tokens themselves are produced by convergence con
Implement convergence control in MIR using SelectionDAG (#71785)
LLVM function calls carry convergence control tokens as operand bundles, where
the tokens themselves are produced by convergence control intrinsics. This patch
implements convergence control tokens in MIR as follows:
1. Introduce target-independent ISD opcodes and MIR opcodes for convergence
control intrinsics.
2. Model token values as untyped virtual registers in MIR.
The change also introduces an additional ISD opcode CONVERGENCECTRL_GLUE and a
corresponding machine opcode with the same spelling. This glues the convergence
control token to SDNodes that represent calls to intrinsics. The glued token is
later translated to an implicit argument in the MIR.
The lowering of calls to user-defined functions is target-specific. On AMDGPU,
the convergence control operand bundle at a non-intrinsic call is translated to
an explicit argument to the SI_CALL_ISEL instruction. Post-selection adjustment
converts this explicit argument to an implicit argument on the SI_CALL
instruction.
show more ...
|
#
fffcc5ca |
| 08-Feb-2024 |
Francesco Petrogalli <francesco.petrogalli@apple.com> |
[CodeGen] Add ValueType v3i8 (NFCI). (#80826)
|
Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6 |
|
#
e1afd063 |
| 23-Nov-2023 |
Maciej Gabka <maciej.gabka@arm.com> |
[NFC] Use TypeSize for comparison in EVT::isExtendedXBitVector functions (#73131)
The functions should not compare results of
getExtendedSizeInBits(), i.e TypeSize variables with plain integer valu
[NFC] Use TypeSize for comparison in EVT::isExtendedXBitVector functions (#73131)
The functions should not compare results of
getExtendedSizeInBits(), i.e TypeSize variables with plain integer values,
but create a fixed TypeSize object so the correct operator can be used.
show more ...
|
#
81b7f115 |
| 22-Nov-2023 |
Sander de Smalen <sander.desmalen@arm.com> |
[llvm][TypeSize] Fix addition/subtraction in TypeSize. (#72979)
It seems TypeSize is currently broken in the sense that:
TypeSize::Fixed(4) + TypeSize::Scalable(4) => TypeSize::Fixed(8)
with
[llvm][TypeSize] Fix addition/subtraction in TypeSize. (#72979)
It seems TypeSize is currently broken in the sense that:
TypeSize::Fixed(4) + TypeSize::Scalable(4) => TypeSize::Fixed(8)
without failing its assert that explicitly tests for this case:
assert(LHS.Scalable == RHS.Scalable && ...);
The reason this fails is that `Scalable` is a static method of class
TypeSize,
and LHS and RHS are both objects of class TypeSize. So this is
evaluating
if the pointer to the function Scalable == the pointer to the function
Scalable,
which is always true because LHS and RHS have the same class.
This patch fixes the issue by renaming `TypeSize::Scalable` ->
`TypeSize::getScalable`, as well as `TypeSize::Fixed` to
`TypeSize::getFixed`,
so that it no longer clashes with the variable in
FixedOrScalableQuantity.
The new methods now also better match the coding standard, which
specifies that:
* Variable names should be nouns (as they represent state)
* Function names should be verb phrases (as they represent actions)
show more ...
|
Revision tags: 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 |
|
#
6a55aa5f |
| 31-Aug-2023 |
Philip Reames <preames@rivosinc.com> |
[CodeGen] Print invalid instead of crashing when dumping invalid MVT
|
Revision tags: 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 |
|
#
5c7c3af1 |
| 08-May-2023 |
Akshay Khadse <akshayskhadse@gmail.com> |
Reapply [Coverity] Fix explicit null dereferences
This change fixes static code analysis errors
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D149506
|
Revision tags: llvmorg-16.0.3 |
|
#
b63c08c7 |
| 24-Apr-2023 |
Tom Weaver <Tom.Weaver@Sony.com> |
Revert "[Coverity] Fix explicit null dereferences"
This reverts commit 22b23a5213b57ce1834f5b50fbbf8a50297efc8a.
This commit caused the following two build bots to start failing: https://lab.llvm.o
Revert "[Coverity] Fix explicit null dereferences"
This reverts commit 22b23a5213b57ce1834f5b50fbbf8a50297efc8a.
This commit caused the following two build bots to start failing: https://lab.llvm.org/buildbot/#/builders/216/builds/20322 https://lab.llvm.org/buildbot/#/builders/123/builds/18511
show more ...
|
#
22b23a52 |
| 23-Apr-2023 |
Akshay Khadse <akshayskhadse@gmail.com> |
[Coverity] Fix explicit null dereferences
This change fixes static code analysis errors
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D148912
|
Revision tags: llvmorg-16.0.2, llvmorg-16.0.1 |
|
#
b333f339 |
| 20-Mar-2023 |
Michal Paszkowski <michal.paszkowski@outlook.com> |
[SPIR-V] Add Machine Value Type for SPIR-V builtins
Differential Revision: https://reviews.llvm.org/D145703
|
Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4 |
|
#
170e7a0e |
| 02-Mar-2023 |
Sander de Smalen <sander.desmalen@arm.com> |
[AArch64][SME2] Add CodeGen support for target("aarch64.svcount").
This patch adds AArch64 CodeGen support such that the type can be passed and returned to/from functions, and also adds support to u
[AArch64][SME2] Add CodeGen support for target("aarch64.svcount").
This patch adds AArch64 CodeGen support such that the type can be passed and returned to/from functions, and also adds support to use this type in load/store operations and PHI nodes.
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D136862
show more ...
|
#
5ac69674 |
| 27-Feb-2023 |
Michal Paszkowski <michal.paszkowski@outlook.com> |
[SPIR-V] Support TargetExtType for SPIR-V builtin types
This patch adds support for TargetExtType/target(...) representing SPIR-V builtin types. After D135202, target(...) is the preferred way for r
[SPIR-V] Support TargetExtType for SPIR-V builtin types
This patch adds support for TargetExtType/target(...) representing SPIR-V builtin types. After D135202, target(...) is the preferred way for representing SPIR-V builtin types in LLVM IR and the only working in the opaque pointer mode.
In order to maintain compatibility with LLVM IR generated by older versions of Clang and LLVM/SPIR-V Translator, pointers-to-opaque-structs denoting SPIR-V/OpenCL builtin types will be translated to equivalent SPIR-V target extension types. This translation is only available in the typed pointer mode (-opaque-pointers=0).
The relevant LIT tests with SPIR-V builtins were converted to use the new target(...) notation.
Differential Revision: https://reviews.llvm.org/D144494
show more ...
|
Revision tags: llvmorg-16.0.0-rc3 |
|
#
890146b1 |
| 18-Feb-2023 |
Paulo Matos <pmatos@igalia.com> |
[WebAssembly] Initial support for reference type externref in clang
This patch introduces a new type __externref_t that denotes a WebAssembly opaque reference type. It also implements builtin __buil
[WebAssembly] Initial support for reference type externref in clang
This patch introduces a new type __externref_t that denotes a WebAssembly opaque reference type. It also implements builtin __builtin_wasm_ref_null_extern(), that returns a null value of __externref_t. This lays the ground work for further builtins and reference types.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122215
show more ...
|
Revision tags: llvmorg-16.0.0-rc2 |
|
#
3be1ae24 |
| 07-Feb-2023 |
Philip Reames <preames@rivosinc.com> |
[CodeGen] Add standard print/debug utilities to MVT
Doing so makes it easier to do printf style debugging in idiomatic manner. I followed the code structure of Value with only the definition of dump
[CodeGen] Add standard print/debug utilities to MVT
Doing so makes it easier to do printf style debugging in idiomatic manner. I followed the code structure of Value with only the definition of dump being #ifdef out in non-debug builds. Not sure if this is the "right" option; we don't seem to have any single consistent scheme on how dump is handled.
Note: This is a follow up to D143454 which did the same for EVT.
Differential Revision: https://reviews.llvm.org/D143511
show more ...
|