History log of /llvm-project/llvm/lib/CodeGen/ValueTypes.cpp (Results 1 – 25 of 95)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


1234