aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Target/SPIRV/SPIRVModuleAnalysis.cpp
AgeCommit message (Collapse)AuthorFilesLines
14 hours[SPIRV] Added constraint for SPV_INTEL_bindless_image extension (#160249)Ebin-McW1-3/+34
Added constraints related to Addressing model as specified in the specification. It conforms with the implementation in translator Same as PR #160089 Solved all issues
14 hours[SPIRV] Add support for the extension ↵Ebin-McW1-0/+31
SPV_EXT_relaxed_printf_string_address_space (#160245) Added support for the extension to support more storageclass for printf strings.
7 days[SPIRV] Add support for the SPIR-V extension SPV_KHR_bfloat16 (#155645)YixingZhang0071-5/+35
This PR introduces the support for the SPIR-V extension `SPV_KHR_bfloat16`. This extension extends the `OpTypeFloat` instruction to enable the use of bfloat16 types with cooperative matrices and dot products. TODO: Per the `SPV_KHR_bfloat16` extension, there are a limited number of instructions that can use the bfloat16 type. For example, arithmetic instructions like `FAdd` or `FMul` can't operate on `bfloat16` values. Therefore, a future patch should be added to either emit an error or fall back to FP32 for arithmetic in cases where bfloat16 must not be used. Reference Specification: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/KHR/SPV_KHR_bfloat16.asciidoc
2025-09-08[SPIRV] Move instead of copy. (#156637)Marcos Maronas1-1/+1
2025-08-06[SPIRV] Fix code quality issues. (#152005)Marcos Maronas1-3/+3
Fix code quality issues reported by static analysis tool, such as: - Rule of Three/Five. - Dereference after null check. - Unchecked return value. - Variable copied when it could be moved.
2025-08-05[SPIRV] Fix buildbot failure after #149522 (#152135)Marcos Maronas1-0/+1
2025-08-05[SPIRV] Do not use OpTypeRuntimeArray in Kernel env. (#149522)Marcos Maronas1-1/+11
Prior to this patch, when `NumElems` was 0, `OpTypeRuntimeArray` was directly generated, but it requires `Shader` capability, so it can only be generated if `Shader` env is being used. We have observed a pattern of using unbound arrays that translate into `[0 x ...]` types in OpenCL, which implies `Kernel` capability, so `OpTypeRuntimeArray` should not be used. To prevent this scenario, this patch simplifies GEP instructions where type is a 0-length array and the first index is also 0. In such scenario, we effectively drop the 0-length array and the first index. Additionally, the newly added test prior to this patch was generating a module with both `Shader` and `Kernel` capabilities at the same time, but they're incompatible. This patch also fixes that. Finally, prior to this patch, the newly added test was adding `Shader` capability to the module even with the command line flag `--avoid-spirv-capabilities=Shader`. This patch also has a fix for that.
2025-08-01[SPIR-V] Add support for the SPIR-V extension ↵YixingZhang0071-0/+7
SPV_INTEL_tensor_float32_conversion (#150090) This PR introduces the support for the SPIR-V extension `SPV_INTEL_tensor_float32_conversion` and the corresponding OpenCL extension `cl_intel_tensor_float32_conversions`. This extension introduces a rounding instruction that converts standard 32-bit floating-point values to the TensorFloat32 (TF32) format. Reference Specification: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/INTEL/SPV_INTEL_tensor_float32_conversion.asciidoc
2025-07-02[SPIRV] Add FloatControl2 capability (#144371)Steven Perron1-4/+24
Add handling for FPFastMathMode in SPIR-V shaders. This is a first pass that simply does a direct translation when the proper extension is available. This will unblock work for HLSL. However, it is not a full solution. The default math mode for spir-v is determined by the API. When targeting Vulkan many of the fast math options are assumed. We should do something particular when targeting Vulkan. We will also need to handle the hlsl "precise" keyword correctly when FPFastMathMode is not available. Unblockes https://github.com/llvm/llvm-project/issues/140739, but we are keeing it open to track the remaining issues mentioned above.
2025-06-12[SPIR-V] Fix ExecutionMode generation (#143888)Nathan Gauër1-2/+0
PR #141787 added code to emit the Fragment execution model. This required emitting the OriginUpperLeft ExecutionMode. But this was done by using the same codepath used for OpEntrypoint. This has 2 issues: - the interface variables were added to both OpEntryPoint and OpExecutionMode. - the existing OpExecutionMode logic was not used. This commit fixes this, regrouping OpExecutionMode handling in one place, and fixing bad codegen issue when interface variiables are added.
2025-06-10[SPIR-V] Add Fragment execution model (#141787)Nathan Gauër1-0/+2
This commits allows the fragment execution model to be set using the hlsl.shader attribute. Fixes #136962
2025-06-03[SPIRV] Change how to detect OpenCL/Vulkan Env and update tests accordingly. ↵Marcos Maronas1-12/+14
(#129689) A new test added for spirv-friendly builtins for SPV_KHR_bit_instructions unveiled that current mechanism to detect whether SPIRV Backend is in OpenCL environment or Vulkan environment was not good enough. This PR updates how to detect the environment and all the tests accordingly. *UPDATE*: the new approach is having a new member in `SPIRVSubtarget` to represent the environment. It can be either OpenCL, Kernel or Unknown. If the triple is explicit, we can directly set it at the creation of the `SPIRVSubtarget`, otherwise we just leave it unknown until we find other information that can help us set the environment. For now, the only other information we use to set the environment is `hlsl.shader` attribute at `SPIRV::ExecutionModel::ExecutionModel getExecutionModel(const SPIRVSubtarget &STI, const Function &F)`. Going forward we should consider also specific instructions that are Kernel-exclusive or Shader-exclusive. --------- Co-authored-by: marcos.maronas <mmaronas@smtp.igk.intel.com>
2025-05-23[NFC][CodeGen] Adopt MachineFunctionProperties convenience accessors (#141101)Rahul Joshi1-1/+1
2025-05-19[SPIR-V] Add SPV_INTEL_2d_block_io extension (#140140)Yury Plyakhin1-0/+24
Adds additional subgroup block prefetch, load, load transposed, load transformed and store instructions to read two-dimensional blocks of data from a two-dimensional region of memory, or to write two-dimensional blocks of data to a two-dimensional region of memory. Spec: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/INTEL/SPV_INTEL_2d_block_io.asciidoc --------- Co-authored-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
2025-04-30SPIRV: Simplify phi processing (#137050)Matt Arsenault1-3/+1
2025-04-24 SPIRV: Set NoPHIs property after rewriting them (#136327)Matt Arsenault1-0/+2
There should be no PHIs after selection, as OpPhi is used instead. This hopefully avoids errors in #135277.
2025-04-23[SPIRV] Support for the SPV_INTEL_subgroup_matrix_multiply_accumulate SPIR-V ↵Vyacheslav Levytskyy1-0/+14
extension (#135225) Adds support for the SPV_INTEL_subgroup_matrix_multiply_accumulate SPIR-V extension according to https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/INTEL/SPV_INTEL_subgroup_matrix_multiply_accumulate.asciidoc
2025-04-09[SPIRV] Support for SPV_INTEL_ternary_bitwise_function (#134866)Steffen Larsen1-0/+11
Adds support for the SPV_INTEL_ternary_bitwise_function extension, adding; * the OpBitwiseFunctionINTEL SPIR-V instruction, a ternary bitwise function where the operation performed is determined by a look-up table index, * and the corresponding TernaryBitwiseFunctionINTEL capability. See https://github.khronos.org/SPIRV-Registry/extensions/INTEL/SPV_INTEL_ternary_bitwise_function.html. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
2025-04-03[NFC] Cleanup pass initialization for SPIRV passes (#134189)Rahul Joshi1-4/+0
- Do not call pass initialization functions from pass contructors. - Instead, call them from SPIRV target initialization. - https://github.com/llvm/llvm-project/issues/111767
2025-04-03[SPIRV] Add spirv.VulkanBuffer types to the backend (#133475)Steven Perron1-1/+32
Adds code to expand the `llvm.spv.resource.handlefrombinding` and `llvm.spv.resource.getpointer` when the resource type is `spirv.VulkanBuffer`. It gets expanded as a storage buffer or uniform buffer denpending on the storage class used. This is implementing part of https://github.com/llvm/wg-hlsl/blob/main/proposals/0018-spirv-resource-representation.md.
2025-03-24[Target] Use *Set::insert_range (NFC) (#132879)Kazu Hirata1-4/+1
We can use *Set::insert_range to collapse: for (auto Elem : Range) Set.insert(E); down to: Set.insert_range(Range); In some cases, we can further fold that into the set declaration.
2025-03-17[SPIR-V] Add `OpConstantCompositeContinuedINTEL` instruction (#129086)Viktoria Maximova1-2/+7
Specification: https://github.khronos.org/SPIRV-Registry/extensions/INTEL/SPV_INTEL_long_composites.html
2025-03-14[SPIR-V] Support SPV_INTEL_fp_max_error extension for `!fpmath` metadata ↵Viktoria Maximova1-0/+3
(#130619) Specification: https://github.khronos.org/SPIRV-Registry/extensions/INTEL/SPV_INTEL_fp_max_error.html
2025-03-06[SPIR-V] Add SPV_INTEL_memory_access_aliasing extension (#129800)Dmitry Sidorov1-0/+9
Spec can be found here https://github.com/intel/llvm/pull/15225 TODO for future patches: - During spec review need to decide whether only FunctionCall or Atomic instructions can be decorated and if not - move the code around adding handling for other instructions; - Handle optional string metadata; - Handle LLVM atomic instructions; - Handle SPIR-V friendly atomic calls returning via sret argument. Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>
2025-03-05[SPIRV] Avoid repeated hash lookups (NFC) (#129826)Kazu Hirata1-11/+12
2025-03-03[SPIR-V] Stop using Register to represent target specific virtual registers. ↵Craig Topper1-16/+17
(#129362) These were using the virtual register encoding in Register which required including Register.h in MC layer code which is a layering violation. This also required converting Register with bit 31 set to MCRegister which should be an error. Register with bit 31 set should only be used for codegen virtual register. I'd like to add assertions to enforce this. Migrate to MCRegister and manually create an encoding with bit 31 set. WebAssembly also does this. We could consider adding interfaces to MCRegister for target specific virtual registers.
2025-02-27[SPIRV] Remove unused variable. NFCCraig Topper1-1/+0
2025-02-24[SPIR-V] Stop generating StorageImageReadWithoutFormat and ↵Vyacheslav Levytskyy1-2/+12
StorageImageWriteWithoutFormat for the Unknown image format in the OpenCL environment (#128497) This PR resolves the issue of the SPIR-V specification, requiring Shader-coupled capabilities to read/write images in the OpenCL SPIR-V environment, from the perspective of the LLVM SPIR-V backend. See https://github.com/KhronosGroup/SPIRV-Headers/issues/487 for details and discussion. Current implementation correctly reproduces requirements of the SPIR-V specification, however, since the requirements are problematic, out current implementation blocks generation of valid SPIR-V code for compute environments. This PR is to implement a solution discussed at the SPIR-V WG to allow proceeding with generation of valid SPIR-V code for the OpenCL environment and do not impact Vulkan environment at the same time.
2025-02-20[SPIR-V] Initial implementation of SPV_INTEL_long_composites (#126545)Viktoria Maximova1-0/+23
This change introduces support of `OpTypeStructContinuedINTEL` instruction. Specification: https://github.khronos.org/SPIRV-Registry/extensions/INTEL/SPV_INTEL_long_composites.html
2025-02-20[SPIR-V] Add SPV_INTEL_bindless_images extension (#127737)Dmitry Sidorov1-0/+11
Adds instructions to convert convert unsigned integer handles to images, samplers and sampled images. Spec: https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_bindless_images.asciidoc --------- Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>
2025-02-05[SPIR-V] Support all the instructions of SPV_KHR_integer_dot_product (#123792)Viktoria Maximova1-0/+4
This continues the work on dot product instructions already started in 3cdac06. This change adds support for all OpenCL integer dot product builtins under `cl_khr_integer_dot_product` extension, namely: ``` * dot * dot_acc_sat * dot_4x8packed_(uu/ss/su/us)_(u)int * dot_acc_sat_4x8packed_(uu/ss/su/us)_(u)int ```
2025-01-28[SPIR-V] Change a way SPIR-V Backend API works with user facing options ↵Vyacheslav Levytskyy1-2/+4
(#124745) This PR fixes https://github.com/llvm/llvm-project/issues/124703: * added a new API call `SPIRVTranslate` that is to replace entirely old `SPIRVTranslateModule` after existing clients switch into the new function; * the new `SPIRVTranslate` doesn't require option parsing, replacing the `Opts` argument with explicit `CodeGenOptLevel` and `Triple` arguments; * the old `SPIRVTranslateModule` call is a wrapper for `SPIRVTranslate`, it doesn't require option parsing either and doesn't hold any logic inside except for converting string options into `CodeGenOptLevel` and `Triple` arguments; * usage of the extensions list is reworked to avoid writes to the global cl::opt variable `lib/Target/SPIRV/SPIRVSubtarget.cpp::Extensions` -- instead a new class member in SPIRVSubtarget.cpp is implemented that allows to replace supported extensions after SPIRVSubtarget.cpp is created; * both API calls don't require option parsing and don't write to global cl::opt variables. Other related/required changes: * SPIRV::Capability::Shader is marked as an capability of lesser priority for OpenCL environment (to remediate absence of the "avoid-spirv-capabilities" command line option in API calls); * unit tests are updated and extended to cover testing of a newer API call; * old API call is marked with TODO to remove it after existing clients switch into the new function.
2025-01-17[SPIRV] Expand RWBuffer load and store from HLSL (#122355)Steven Perron1-2/+4
The code pattern that clang will generate for HLSL has changed from the original plan. This allows the SPIR-V backend to generate code for the current code generation. It looks for patterns of the form: ``` %1 = @llvm.spv.resource.handlefrombinding %2 = @llvm.spv.resource.getpointer(%1, index) load/store %2 ``` These three llvm-ir instruction are treated as a single unit that will 1. Generate or find the global variable identified by the call to `resource.handlefrombinding`. 2. Generate an OpLoad of the variable to get the handle to the image. 3. Generate an OpImageRead or OpImageWrite using that handle with the given index. This will generate the OpLoad in the same BB as the read/write. Note: Now that `resource.handlefrombinding` is not processed on its own, many existing tests had to be removed. We do not have intrinsics that are able to use handles to sampled images, input attachments, etc., so we cannot generate the load of the handle. These tests are removed for now, and will be added when those resource types are fully implemented.
2025-01-16[HLSL][SPIRV][DXIL] Implement `WaveActiveSum` intrinsic (#118580)Adam Yang1-2/+0
``` - add clang builtin to Builtins.td - link builtin in hlsl_intrinsics - add codegen for spirv intrinsic and two directx intrinsics to retain signedness information of the operands in CGBuiltin.cpp - add semantic analysis in SemaHLSL.cpp - add lowering of spirv intrinsic to spirv backend in SPIRVInstructionSelector.cpp - add lowering of directx intrinsics to WaveActiveOp dxil op in DXIL.td - add test cases to illustrate passespendent pr merges. ``` Resolves #70106 --------- Co-authored-by: Finn Plummer <canadienfinn@gmail.com>
2025-01-09[SPIR-V] Prefer SPV_INTEL_optnone over SPV_EXT_optnone when both extensions ↵Vyacheslav Levytskyy1-4/+4
are available (#122082) This PR fixes https://github.com/llvm/llvm-project/issues/122075. We prefer SPV_INTEL_optnone over SPV_EXT_optnone when both extensions are available, otherwise, when a target specifies a required extension explicitly rather than allowing any of those (e.g., by providing --spirv-ext=all command line argument), the Backend's behavior remains unchanged. An existing test case is updated to check the case of 2 alternative extensions available at the same time.
2025-01-07[SPIR-V] Overhaul module analysis to improve translation speed and simplify ↵Vyacheslav Levytskyy1-134/+238
the underlying logics (#120415) This PR is to address legacy issues with module analysis that currently uses a complicated and not so efficient approach to trace dependencies between SPIR-V id's via a duplicate tracker data structures and an explicitly built dependency graph. Even a quick performance check without any specialized benchmarks points to this part of the implementation as a biggest bottleneck. This PR specifically: * eliminates a need to build a dependency graph as a data structure, * updates the test suite (mainly, by fixing incorrect CHECK's referring to a hardcoded order of definitions, contradicting the spec requirement to allow certain definitions to go "in any order", see https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html#_logical_layout_of_a_module), * improves function pointers implementation so that it now passes EXPENSIVE_CHECKS (thus removing 3 XFAIL's in the test suite). As a quick sanity check of whether goals of the PR are achieved, we can measure time of translation for any big LLVM IR. While testing the PR in the local development environment, improvements of the x5 order have been observed. For example, the SYCL test case "group barrier" that is a ~1Mb binary IR input shows the following values of the naive performance metric that we can nevertheless apply here to roughly estimate effects of the PR. before the PR: ``` $ time llc -O0 -mtriple=spirv64v1.6-unknown-unknown _group_barrier_phi.bc -o 1 --filetype=obj real 3m33.241s user 3m14.688s sys 0m18.530s ``` after the PR ``` $ time llc -O0 -mtriple=spirv64v1.6-unknown-unknown _group_barrier_phi.bc -o 1 --filetype=obj real 0m42.031s user 0m38.834s sys 0m3.193s ``` Next work should probably address Duplicate Tracker further, as it needs analysis now from the perspective of what parts of it are not necessary now, after changing the approach to implementation of the module analysis step.
2024-12-16[SPIR-V] Add saturation and float rounding mode decorations, a subset of ↵Vyacheslav Levytskyy1-4/+21
arithmetic constrained floating-point intrinsics, and SPV_INTEL_float_controls2 extension (#119862) This PR adds the following features: * saturation and float rounding mode decorations, * arithmetic constrained floating-point intrinsics (strict_fadd, strict_fsub, strict_fmul, strict_fdiv, strict_frem, strict_fma and strict_fldexp), * and SPV_INTEL_float_controls2 extension, * using recent improvements of emit-intrinsics step, this PR also simplifies pre- and post-legalizer steps and improves instruction selection.
2024-12-09[SPIR-V] Improve general validity of emitted code between passes (#119202)Vyacheslav Levytskyy1-0/+23
This PR improves general validity of emitted code between passes due to generation of `TargetOpcode::PHI` instead of `SPIRV::OpPhi` after Instruction Selection, fixing generation of OpTypePointer instructions and using of proper virtual register classes. Using `TargetOpcode::PHI` instead of `SPIRV::OpPhi` after Instruction Selection has a benefit to support existing optimization passes immediately, as an alternative path to disable those passes that use `MI.isPHI()`. This PR makes it possible thus to revert https://github.com/llvm/llvm-project/pull/116060 actions and get back to use the `MachineSink` pass. This PR is a solution of the problem discussed in details in https://github.com/llvm/llvm-project/pull/110507. It accepts an advice from code reviewers of the PR #110507 to postpone generation of OpPhi rather than to patch CodeGen. This solution allows to unblock improvements wrt. expensive checks and makes it unrelated to the general points of the discussion about OpPhi vs. G_PHI/PHI. This PR contains numerous small patches of emitted code validity that allows to substantially pass rate with expensive checks. Namely, the test suite with expensive checks set ON now has only 12 fails out of 569 total test cases. FYI @bogner
2024-12-04[SPIR-V] Add SPV_INTEL_joint_matrix extension (#118578)Dmitry Sidorov1-0/+132
The spec is available here: https://github.com/intel/llvm/pull/12497 The PR doesn't add OpCooperativeMatrixApplyFunctionINTEL instruction as it's still experimental and not properly tested E2E. The PR also fixes few bugs in the related code: 1. CooperativeMatrixMulAddKHR optional operand must be literal, not a constant; 2. Fixed available capabilities table creation for a case, when a single extension adds few capabilities, that occupy not contiguous op codes. --------- Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>
2024-12-03[SPIR-V] Fix emission of debug and annotation instructions and add ↵Vyacheslav Levytskyy1-5/+31
SPV_EXT_optnone SPIR-V extension (#118402) This PR fixes: * emission of OpNames (added newly inserted internal intrinsics and basic blocks) * emission of function attributes (SRet is added) * implementation of SPV_INTEL_optnone so that it emits OptNoneINTEL Function Control flag, and add implementation of the SPV_EXT_optnone SPIR-V extension.
2024-12-03Add support for SPIR-V extension: SPV_INTEL_media_block_io (#118024)Viktoria Maximova1-0/+7
This changes implements SPV_INTEL_media_block_io extension in SPIR-V backend.
2024-11-21[SPIRV] Use `Op[S|U]Dot` when possible for integer dot product (#115095)Finn Plummer1-9/+15
``` - use the new OpSDot/OpUDot instructions when capabilites allow in SPIRVInstructionSelector.cpp - correct functionality of capability check onto input operand and not return operand type in SPIRVModuleAnalysis.cpp - add test cases to demonstrate use case in idot.ll ``` Resolves #114632
2024-11-21[HLSL] Implement WaveActiveAnyTrue intrinsic (#115902)Ashley Coleman1-8/+9
Resolves https://github.com/llvm/llvm-project/issues/99160 - [x] Implement `WaveActiveAnyTrue` clang builtin, - [x] Link `WaveActiveAnyTrue` clang builtin with `hlsl_intrinsics.h` - [x] Add sema checks for `WaveActiveAnyTrue` to `CheckHLSLBuiltinFunctionCall` in `SemaChecking.cpp` - [x] Add codegen for `WaveActiveAnyTrue` to `EmitHLSLBuiltinExpr` in `CGBuiltin.cpp` - [x] Add codegen tests to `clang/test/CodeGenHLSL/builtins/WaveActiveAnyTrue.hlsl` - [x] Add sema tests to `clang/test/SemaHLSL/BuiltIns/WaveActiveAnyTrue-errors.hlsl` - [x] Create the `int_dx_WaveActiveAnyTrue` intrinsic in `IntrinsicsDirectX.td` - [x] Create the `DXILOpMapping` of `int_dx_WaveActiveAnyTrue` to `113` in `DXIL.td` - [x] Create the `WaveActiveAnyTrue.ll` and `WaveActiveAnyTrue_errors.ll` tests in `llvm/test/CodeGen/DirectX/` - [x] Create the `int_spv_WaveActiveAnyTrue` intrinsic in `IntrinsicsSPIRV.td` - [x] In SPIRVInstructionSelector.cpp create the `WaveActiveAnyTrue` lowering and map it to `int_spv_WaveActiveAnyTrue` in `SPIRVInstructionSelector::selectIntrinsic`. - [x] Create SPIR-V backend test case in `llvm/test/CodeGen/SPIRV/hlsl-intrinsics/WaveActiveAnyTrue.ll` --------- Co-authored-by: Finn Plummer <50529406+inbelic@users.noreply.github.com> Co-authored-by: Greg Roth <grroth@microsoft.com>
2024-11-18[SPIRV] Add write to image buffer for shaders. (#115927)Steven Perron1-1/+10
This commit adds an intrinsic that will write to an image buffer. We chose to match the name of the DXIL intrinsic for simplicity in clang. We cannot reuse the existing openCL write_image function because that is not a reserved name in HLSL. There is not much common code to factor out.
2024-11-14[HLSL] Adding HLSL `clip` function. (#114588)joaosaffran1-1/+15
Adding HLSL `clip` function. - adding llvm intrinsic - adding sema checks - adding dxil lowering - ading spirv lowering - adding sema tests - adding codegen tests - adding lowering tests Closes #99093 --------- Co-authored-by: Joao Saffran <jderezende@microsoft.com>
2024-11-12[SPIRV] Add reads from image buffer for shaders. (#115178)Steven Perron1-1/+21
This commit adds an intrinsic that will read from an image buffer. We chose to match the name of the DXIL intrinsic for simplicity in clang. We cannot reuse the existing openCL readimage function because that is not a reserved name in HLSL. I considered trying to refactor generateReadImageInst, so that we could share code between the two implementations. However, most of the code in generateReadImageInst is concerned with trying to figure out which type of image read is being done. Once we factor out the code that will be common, then we end up with just a single call to the MIRBuilder being common.
2024-11-05[HLSL][SPIRV][DXIL] Implement `dot4add_i8packed` intrinsic (#113623)Finn Plummer1-16/+51
- create a clang built-in in Builtins.td - link dot4add_i8packed in hlsl_intrinsics.h - add lowering to spirv backend through expansion of operation as OPSDot is missing up to SPIRV 1.6 in SPIRVInstructionSelector.cpp - add lowering to spirv backend using OpSDot in applicable SPIRV version or if SPV_KHR_integer_dot_product is enabled - add dot4add_i8packed intrinsic to IntrinsicsDirectX.td and mapping to DXIL.td op Dot4AddI8Packed - add tests for HLSL intrinsic lowering to dx/spv intrinsic in dot4add_i8packed.hlsl - add tests for sema checks in dot4add_i8packed-errors.hlsl - add test of spir-v lowering in SPIRV/dot4add_i8packed.ll - add test to dxil lowering in DirectX/dot4add_i8packed.ll Resolves #99220
2024-10-30[SPIRV][HLSL] Handle arrays of resources (#111564)Steven Perron1-3/+161
This commit adds the ability to get a particular resource from an array of resources using the handle_fromBinding intrinsic. The main changes are: 1. Create an array when generating the type. 2. Add capabilities from [SPV_EXT_descriptor_indexing](https://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/EXT/SPV_EXT_descriptor_indexing.html). We are still missing the ability to declare a runtime array. That will be done in a follow up PR.
2024-10-15[SPIR-V] Implement support of the SPV_INTEL_split_barrier SPIRV extension ↵Vyacheslav Levytskyy1-0/+7
(#112359) This PR implements support of the SPV_EXT_arithmetic_fence SPIRV extension (https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/INTEL/SPV_INTEL_split_barrier.asciidoc) and adds builtins from https://registry.khronos.org/OpenCL/extensions/intel/cl_intel_split_work_group_barrier.html
2024-10-07[SPIR-V] Emit DebugTypePointer from NonSemantic DI (#109287)bwlodarcz1-1/+1
Implementation of DebugTypePointer from NonSemantic.Shader.DebugInfo.100.