#
0d9172ec |
| 26-Jun-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Improve pattern matching and tracking of constant integers (#96615)
This PR fixes the issue
https://github.com/llvm/llvm-project/issues/96614 by improve pattern
matching and tracking of c
[SPIR-V] Improve pattern matching and tracking of constant integers (#96615)
This PR fixes the issue
https://github.com/llvm/llvm-project/issues/96614 by improve pattern
matching and tracking of constant integers. The attached test is
successful if it doesn't crash and generate valid SPIR-V code for both
32 and 64 bits targets.
show more ...
|
#
f6aa5087 |
| 25-Jun-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V]: Fix creation of constants of array types in SPIRV Backend (#96514)
This PR fixes https://github.com/llvm/llvm-project/issues/96513.
The way of creation of array type constant was incorr
[SPIR-V]: Fix creation of constants of array types in SPIRV Backend (#96514)
This PR fixes https://github.com/llvm/llvm-project/issues/96513.
The way of creation of array type constant was incorrect: instead of
creating [1, 1, 1] or [1, 1, 1, 1, 1, ....] constants, the same [1]
constant was always created, substituting original composite constants.
This in its turn led to a situation when only one of constants might
exist in the code without emitting invalid code, the second constant
would be eventually rewritten to the first constant, because a key to
address both was an array of a single element (like [1]).
This PR fixes the issue and purges from the code unneeded copy/pasted
clone of the function that creates an array constant.
show more ...
|
#
b0efde6d |
| 24-Jun-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V]: Improve pattern matching to recognize a composite constant to be a constant (#96286)
This PR is to fix https://github.com/llvm/llvm-project/issues/96285 by:
* improve pattern matching to
[SPIR-V]: Improve pattern matching to recognize a composite constant to be a constant (#96286)
This PR is to fix https://github.com/llvm/llvm-project/issues/96285 by:
* improve pattern matching to recognize an aggregate constant to be a
constant
* do not emit Bitcast for an aggregate type
show more ...
|
#
57f79371 |
| 24-Jun-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V]: Add SPIR-V extension: SPV_KHR_cooperative_matrix (#96091)
This PR adds SPIR-V extension SPV_KHR_cooperative_matrix that "adds a
new set of types known as "cooperative matrix" types, where
[SPIR-V]: Add SPIR-V extension: SPV_KHR_cooperative_matrix (#96091)
This PR adds SPIR-V extension SPV_KHR_cooperative_matrix that "adds a
new set of types known as "cooperative matrix" types, where the storage
for and computations performed on the matrix are spread across a set of
invocations such as a subgroup" (see
https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_cooperative_matrix.asciidoc).
This PR also fixes https://github.com/llvm/llvm-project/issues/96170, a
new test cases is attached
(llvm/test/CodeGen/SPIRV/transcoding/OpPtrCastToGeneric.ll).
show more ...
|
#
2ae6889d |
| 20-Jun-2024 |
Farzon Lotfi <1802579+farzonl@users.noreply.github.com> |
[SPIRV] Add trig function lowering (#95973)
This change is part of this proposal:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
This is part 2 of 4 PRs. It sets the ground work
[SPIRV] Add trig function lowering (#95973)
This change is part of this proposal:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
This is part 2 of 4 PRs. It sets the ground work for adding the
intrinsics.
Add SPIRV Lower for `acos`, `asin`, `atan`, `cosh`, `sinh`, and `tanh`
https://github.com/llvm/llvm-project/issues/70079
https://github.com/llvm/llvm-project/issues/70080
https://github.com/llvm/llvm-project/issues/70081
https://github.com/llvm/llvm-project/issues/70083
https://github.com/llvm/llvm-project/issues/70084
https://github.com/llvm/llvm-project/issues/95966
There isn't any aarch64 change in this pr, but when you add a target
opcode it is visible in there validaiton tests.
show more ...
|
#
35a2b609 |
| 18-Jun-2024 |
Helena Kotas <hekotas@microsoft.com> |
[SPIRV][HLSL] Add lowering of `rsqrt` to SPIRV (#95849)
Add lowering of `rsqrt` to SPIRV.
Fixes #88949
|
Revision tags: llvmorg-18.1.8 |
|
#
9a737109 |
| 07-Jun-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Improve type inference, addrspacecast and dependencies between SPIR-V entities and required capability/extensions (#94626)
This PR continues https://github.com/llvm/llvm-project/pull/94467
[SPIR-V] Improve type inference, addrspacecast and dependencies between SPIR-V entities and required capability/extensions (#94626)
This PR continues https://github.com/llvm/llvm-project/pull/94467 and
contains fixes in emission of type intrinsics, constant recording and
corresponding test cases:
* type-deduce-global-dup.ll -- fix of integer constant emission on
32-bit platforms and correct type deduction for globals
* type-deduce-simple-for.ll -- fix of GEP translation (there was an
issue previously that led to incorrect translation/broken logic of
for-range implementation)
This PR also:
* fixes a cast between identical storage classes and updates the test
case to include validation run by spirv-val,
* ensures that Bitcast for pointers satisfies the requirement that the
address spaces must match and adds the corresponding test case,
* improve encode in Tablegen and decode in code of dependencies between
SPIR-V entities and required capability/extensions,
* prevent emission of identical OpTypePointer instructions.
show more ...
|
Revision tags: llvmorg-18.1.7, llvmorg-18.1.6 |
|
#
cf9a5a16 |
| 14-May-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Support saturation arithmetic intrinsics in SPIR-V Backend (#91722)
This PR is to support saturation arithmetic intrinsics in SPIR-V
Backend.
|
#
3e82442f |
| 08-May-2024 |
Farzon Lotfi <1802579+farzonl@users.noreply.github.com> |
[SPIRV] Add tan intrinsic part 3 (#90278)
This change is an implementation of #87367's investigation on supporting
IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://dis
[SPIRV] Add tan intrinsic part 3 (#90278)
This change is an implementation of #87367's investigation on supporting
IEEE math operations as intrinsics.
Which was discussed in this RFC:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
If you want an overarching view of how this will all connect see:
https://github.com/llvm/llvm-project/pull/90088
Changes:
- `llvm/docs/GlobalISel/GenericOpcode.rst` - Document the `G_FTAN`
opcode
- `llvm/include/llvm/IR/Intrinsics.td` - Create the tan intrinsic
- `llvm/include/llvm/Support/TargetOpcodes.def` - Create a `G_FTAN`
Opcode handler
- `llvm/include/llvm/Target/GenericOpcodes.td` - Define the `G_FTAN`
Opcode
- `llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp` Map the tan intrinsic
to `G_FTAN` Opcode
- `llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp` - Map the
`G_FTAN` opcode to the GLSL 4.5 and openCL tan instructions.
- `llvm/lib/Target/SPIRV/SPIRVLegalizerInfo.cpp` - Define `G_FTAN` as a
legal spirv target opcode.
show more ...
|
Revision tags: llvmorg-18.1.5 |
|
#
486ea1ec |
| 24-Apr-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Fix pre-legalizer pass in SPIR-V Backend to support more gMIR opcode inserted by IRTranslator (#89890)
Translating global values, IRTranslator pass can sometimes generates
code patterns th
[SPIR-V] Fix pre-legalizer pass in SPIR-V Backend to support more gMIR opcode inserted by IRTranslator (#89890)
Translating global values, IRTranslator pass can sometimes generates
code patterns that require additional efforts during pre-legalization.
This PR addresses this problem to support G_PTRTOINT instruction used in
initialization of GV.
show more ...
|
#
89d12556 |
| 24-Apr-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
Bit width of input/result types in OpSConvert/OpUConvert must not be the same (#89737)
This PR fixes the issue
https://github.com/llvm/llvm-project/issues/88908
Attached test case is updated to ch
Bit width of input/result types in OpSConvert/OpUConvert must not be the same (#89737)
This PR fixes the issue
https://github.com/llvm/llvm-project/issues/88908
Attached test case is updated to check that OpSConvert/OpUConvert is not
generated when input and result types are identical.
show more ...
|
#
c4c54af5 |
| 22-Apr-2024 |
Farzon Lotfi <1802579+farzonl@users.noreply.github.com> |
[SPIRV][HLSL] map lerp to Fmix (#88976)
- `clang/lib/CodeGen/CGBuiltin.cpp` - switch to using
`getLerpIntrinsic()` to abstract backend intrinsic
- `clang/lib/CodeGen/CGHLSLRuntime.h` - add `getLer
[SPIRV][HLSL] map lerp to Fmix (#88976)
- `clang/lib/CodeGen/CGBuiltin.cpp` - switch to using
`getLerpIntrinsic()` to abstract backend intrinsic
- `clang/lib/CodeGen/CGHLSLRuntime.h` - add `getLerpIntrinsic()`
- `llvm/include/llvm/IR/IntrinsicsSPIRV.td` - add SPIRV intrinsic for
lerp
- `llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp` - add mapping of
HLSL's lerp to GLSL's Fmix.
resolves #88940
show more ...
|
#
b512df66 |
| 17-Apr-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Improve Tablegen instruction selection and account for a pointer size of the target (#88725)
This PR resolves the issue that SPIR-V Backend uses the notion of a
pointer size of the target,
[SPIR-V] Improve Tablegen instruction selection and account for a pointer size of the target (#88725)
This PR resolves the issue that SPIR-V Backend uses the notion of a
pointer size of the target, most notably, in legalizer code, but
Tablegen instruction selection in SPIR-V Backend doesn't account for a
pointer size of the target. See
https://github.com/llvm/llvm-project/issues/88723 for a detailed
description. There are 3 test cases attached to the PR that reproduced
the issue, when dealing with spirv32-spirv64 differences, and are
working correctly now with this PR.
show more ...
|
Revision tags: llvmorg-18.1.4 |
|
#
105dcc88 |
| 15-Apr-2024 |
Farzon Lotfi <1802579+farzonl@users.noreply.github.com> |
[HLSL][SPIRV] Add any intrinsic lowering (#88325)
- `CGBuiltin.cpp` - Switch to using
`CGM.getHLSLRuntime().get##NAME##Intrinsic()`
- `CGHLSLRuntime.h` - Add any to backend intrinsic abstraction
[HLSL][SPIRV] Add any intrinsic lowering (#88325)
- `CGBuiltin.cpp` - Switch to using
`CGM.getHLSLRuntime().get##NAME##Intrinsic()`
- `CGHLSLRuntime.h` - Add any to backend intrinsic abstraction
- `IntrinsicsSPIRV.td` - Add any intrinsic to SPIR-V.
- `SPIRVInstructionSelector.cpp` - Add means of selecting any intrinsic.
Any and All share the same behavior up to the opCode. They are only
different in vector cases.
Completes #88045
show more ...
|
#
05093e24 |
| 10-Apr-2024 |
Farzon Lotfi <1802579+farzonl@users.noreply.github.com> |
[Spirv][HLSL] Add OpAll lowering and float vec support (#87952)
The main point of this change was to add support for HLSL's all
intrinsic.
In the process of doing that I found a few issues around
[Spirv][HLSL] Add OpAll lowering and float vec support (#87952)
The main point of this change was to add support for HLSL's all
intrinsic.
In the process of doing that I found a few issues around creating an
`OpConstantComposite` via `buildZerosVal`.
First the current code didn't support floats so the process of adding
`buildZerosValF` meant I needed a
float version of `getOrCreateIntConstVector`. After doing so I renamed
both versions to `getOrCreateConstVector`. That meant I needed to create
a float type version of `getOrCreateIntCompositeOrNull`. Luckily the
type information was low for this function so was able to split it out
into a helpwe and rename `getOrCreateIntCompositeOrNull` to
`getOrCreateCompositeOrNull` With the exception of type handling
differences of the code and Null vs 0 Constant Op codes these functions
should be identical.
To handle scalar floats I could not use `buildConstantFP` like this PR
did:
https://github.com/llvm/llvm-project/commit/0a2aaab5aba46#diff-733a189c5a8c3211f3a04fd6e719952a3fa231eadd8a7f11e6ecf1e584d57411R1603
because that would create too many superfluous registers (that causes
problems in the validator), I had to create a float version of
`getOrCreateConstInt` which I called `getOrCreateConstFP`.
similar problems with doing it like this:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/SPIRV/SPIRVBuiltins.cpp#L1540.
`buildZerosValF` also has a use of a function `getZeroFP`. This is
because half, float, and double scalar values of 0 would collide in
`SPIRVDuplicatesTracker<Constant> CT` if you use `APFloat(0.0f)`.
`getORCreateConstFP` needed its own version of `getOrCreateConstIntReg`
which I called `getOrCreateConstFloatReg` The one difference in this
function is `getOrCreateConstFloatReg` returns a bit width so we don't
have to call `getScalarOrVectorBitWidth` twice ie when it is used again
in `getOrCreateConstFP` for `OpConstantF` `addNumImm`.
`getOrCreateConstFloatReg` needed an `assignFloatTypeToVReg` helper
which called a `getOrCreateSPIRVFloatType` helper. There was no
equivalent IntegerType::get for floats so I handled this with a switch
statement on bit widths to get the right LLVM float type.
Finally, there is the use of `bool ZeroAsNull = STI.isOpenCLEnv();` This
is partly a cosmetic change. When Zeros are treated as nulls, we don't
create `OpConstantComposite` vectors which is something we do in the
DXCs SPIRV backend. The DXC SPIRV backend also does not use
`OpConstantNull`. Finally, I needed a means to test the behavior of the
OpConstantNull and `OpConstantComposite` changes and this was one way I
could do that via the same tests.
show more ...
|
#
1e44d9ac |
| 09-Apr-2024 |
Natalie Chouinard <sudonatalie@google.com> |
[SPIR-V] Map llvm.{min,max}num to GL::N{Min,Max} (#88009)
SPIR-V intsruction selection was mapping the LLVM float min/max
intrinsics to FMin and FMax respectively for GL/Vulkan environments,
which
[SPIR-V] Map llvm.{min,max}num to GL::N{Min,Max} (#88009)
SPIR-V intsruction selection was mapping the LLVM float min/max
intrinsics to FMin and FMax respectively for GL/Vulkan environments,
which does not match the intrinsics' documented treatment of NaN
operands. This patch switches the mapping to the correctly matched NMin
and NMax operations.
Fixes #87072
show more ...
|
#
47e996d8 |
| 04-Apr-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Fix OpVariable instructions place in a function (#87554)
This PR:
* fixes OpVariable instructions place in a function (see
https://github.com/llvm/llvm-project/issues/66261),
* improves
[SPIR-V] Fix OpVariable instructions place in a function (#87554)
This PR:
* fixes OpVariable instructions place in a function (see
https://github.com/llvm/llvm-project/issues/66261),
* improves type inference,
* helps avoiding unneeded bitcasts when validating function call's
This allows to improve existing and add new test cases with more strict
checks. OpVariable fix refers to "All OpVariable instructions in a
function must be the first instructions in the first block" requirement
from SPIR-V spec.
show more ...
|
Revision tags: llvmorg-18.1.3 |
|
#
b7ac8fdd |
| 28-Mar-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Improve type inference: deduce types of composite data structures (#86782)
This PR improves type inference in general and deduces types of
composite data structures in particular. Also add
[SPIR-V] Improve type inference: deduce types of composite data structures (#86782)
This PR improves type inference in general and deduces types of
composite data structures in particular. Also added a way to insert a
bitcast to make a fun call valid in case of arguments types mismatch due
to opaque pointers type inference.
The attached test `pointers/nested-struct-opaque-pointers.ll`
demonstrates new capabilities: the SPIRV code emitted for this test is
now (1) valid in a sense of data field types and (2) accepted by
`spirv-val`.
More strict LIT checks, support of more composite data structures and
improvement of fun calls from the perspective of type correctness are
main todo's at the moment.
show more ...
|
#
b0d03ccc |
| 25-Mar-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Fix illegal OpConstantComposite instruction with non-const constituents in SPIR-V Backend (#86352)
This PR fixes illegal use of OpConstantComposite with non-constant
constituents. The test
[SPIR-V] Fix illegal OpConstantComposite instruction with non-const constituents in SPIR-V Backend (#86352)
This PR fixes illegal use of OpConstantComposite with non-constant
constituents. The test attached to the PR is able now to satisfy
`spirv-val` check. Before the fix SPIR-V Backend produced for the
attached test case a pattern like
```
%a = OpVariable %_ptr_CrossWorkgroup_uint CrossWorkgroup %uint_123
%11 = OpConstantComposite %_struct_6 %a %a
```
so that `spirv-val` complained with
```
error: line 25: OpConstantComposite Constituent <id> '10[%a]' is not a constant or undef.
%11 = OpConstantComposite %_struct_6 %a %a
```
show more ...
|
#
1d250d90 |
| 25-Mar-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Improve type inference in SPIR-V Backend for opaque pointers (#86283)
This PR improves type inference in SPIR-V Backend for opaque pointers,
accounting or a case when there is a chain of f
[SPIR-V] Improve type inference in SPIR-V Backend for opaque pointers (#86283)
This PR improves type inference in SPIR-V Backend for opaque pointers,
accounting or a case when there is a chain of function calls that allows
to deduce formal parameter types from actual arguments. The attached
test demonstrates the case.
show more ...
|
#
c2483ed5 |
| 20-Mar-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIRV] Add __spirv_ builtins for existing instructions (#85654)
This PR:
* adds __spirv_ builtins for existing instructions;
* fixes parsing of "syncscope" values in atomic instructions;
* fix a
[SPIRV] Add __spirv_ builtins for existing instructions (#85654)
This PR:
* adds __spirv_ builtins for existing instructions;
* fixes parsing of "syncscope" values in atomic instructions;
* fix a special case of binary header emision.
show more ...
|
Revision tags: llvmorg-18.1.2 |
|
#
59f34e8c |
| 18-Mar-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIRV] Add Lifetime intrinsics/instructions (#85391)
This PR:
* adds Lifetime intrinsics/instructions
* fixes how the binary header is emitted (correct version and better
approximation of Bound)
[SPIRV] Add Lifetime intrinsics/instructions (#85391)
This PR:
* adds Lifetime intrinsics/instructions
* fixes how the binary header is emitted (correct version and better
approximation of Bound)
* add validation into more test cases
show more ...
|
#
0a443f13 |
| 13-Mar-2024 |
Vyacheslav Levytskyy <vyacheslav.levytskyy@intel.com> |
[SPIR-V] Add implementation of G_SPLAT_VECTOR opcode and fix invalid types processing (#84766)
This PR:
* adds support for G_SPLAT_VECTOR generic opcode that may be legally
generated instead of G_
[SPIR-V] Add implementation of G_SPLAT_VECTOR opcode and fix invalid types processing (#84766)
This PR:
* adds support for G_SPLAT_VECTOR generic opcode that may be legally
generated instead of G_BUILD_VECTOR by previous passes of the translator
(see https://github.com/llvm/llvm-project/pull/80378 for the source of
breaking changes);
* improves deduction of types for opaque pointers.
This PR also fixes the following issues:
* if a function has ptr argument(s), two functions that have different
SPIR-V type definitions may get identical LLVM function types and break
agreements of global register and duplicate checker;
* checks for pointer types do not account for TypedPointerType.
Update of tests:
* A test case is added to cover the issue with function ptr parameters.
* The first case, that is support for G_SPLAT_VECTOR generic opcode, is
covered by existing test cases.
* Multiple additional checks by `spirv-val` is added to cover more
possibilities of generation of invalid code.
show more ...
|
Revision tags: llvmorg-18.1.1 |
|
#
6325dd57 |
| 04-Mar-2024 |
Natalie Chouinard <sudonatalie@google.com> |
[HLSL][SPIR-V] Add SV_DispatchThreadID semantic support (#82536)
Add SPIR-V backend support for the HLSL SV_DispatchThreadID semantic
attribute, which is lowered to a @llvm.dx.thread.id intrinsic i
[HLSL][SPIR-V] Add SV_DispatchThreadID semantic support (#82536)
Add SPIR-V backend support for the HLSL SV_DispatchThreadID semantic
attribute, which is lowered to a @llvm.dx.thread.id intrinsic in LLVM
IR. In the SPIR-V backend, this is now correctly translated to a
`GlobalInvocationId` builtin variable.
Fixes #82534
show more ...
|
#
ecc3bdaa |
| 04-Mar-2024 |
Vyacheslav Levytskyy <89994100+VyacheslavLevytskyy@users.noreply.github.com> |
[SPIR-V] Fix bitcast legalization/instruction selection in SPIR-V Backend (#83139)
This PR is to fix a way how SPIR-V Backend describes legality of
OpBitcast instruction and how it is validated on
[SPIR-V] Fix bitcast legalization/instruction selection in SPIR-V Backend (#83139)
This PR is to fix a way how SPIR-V Backend describes legality of
OpBitcast instruction and how it is validated on a step of instruction
selection. Instead of checking a size of virtual registers (that makes
no sense due to lack of guarantee of direct relations between size of
virtual register and bit width associated with the type size), this PR
allows to legalize OpBitcast without size check and postpones validation
to the instruction selection step.
As an example, let's consider the next example that was copied as is
from a bigger test suite:
```
%355:id(s16) = G_BITCAST %301:id(s32)
%303:id(s16) = ASSIGN_TYPE %355:id(s16), %349:type(s32)
%644:fid(s32) = G_FMUL %645:fid, %646:fid
%301:id(s32) = ASSIGN_TYPE %644:fid(s32), %40:type(s32)
```
Without the PR this leads to a crash with complains to an illegal
bitcast, because %355 is s16 and %301 is s32. However, we must check not
virtual registers in this case, but types of %355 and %301, i.e.,
%349:type(s32) and %40:type(s32), which are perfectly well compatible in
a sense of OpBitcast in this case.
In a test case that is a part of this PR OpBitcast is legal, being
applied for `OpTypeInt 16` and `OpTypeFloat 16`, but would not be
legalized without this PR due to virtual registers defined as having
size 16 and 32.
show more ...
|