From 347be162ccaa84b9a356b0c68e670c099a65d0c2 Mon Sep 17 00:00:00 2001 From: Steven Perron Date: Thu, 28 Nov 2024 11:36:10 -0500 Subject: [PATCH] Add alternatives --- .../NNNN-inline-spirv-function-attributes.md | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/proposals/NNNN-inline-spirv-function-attributes.md b/proposals/NNNN-inline-spirv-function-attributes.md index 2e16e91..600321e 100644 --- a/proposals/NNNN-inline-spirv-function-attributes.md +++ b/proposals/NNNN-inline-spirv-function-attributes.md @@ -67,8 +67,33 @@ HLSL Attribute | Applicab `vk::ext_literal` | Parameters of functions with `vk::ext_instruction` | `"spv.literal"` | The parameter is encoded as a literal in the SPIR-V instruction instead of generating an `OpConstant`. `vk::ext_reference` | Parameters of functions with `vk::ext_instruction` | N/A (handled in Clang) | The parameter's type is modified to a reference type in the Clang AST. (Address space handling needs further investigation.) +TODO: Discuss optimizations. + ## Detailed design ## Alternatives considered (Optional) +When implementing the extension and capability attributes, they could be +represented as a target type: `target("spv.capability", )` and +`target("spv.extension.")`. We could then have some way of add these as +extra parameter to the function. This is not a desirable solution for functions +because it is less straight forward. The llvm-ir will be harder to read, and the +code to generate the function will contain code that does not follow common code +patterns. + +Another alternative is to add metadata nodes that contain this information. The +OpenCL FE uses metadata to pass information to the SPIR-V backend. One example +is the `spirv.Decorations` metadata nodes to adding decorations to values. We +chose not to use metadata because metadata is supposed to "convey extra +information about the code to the optimizers and code generator." However, these +attributes do not represent extra information. Instead, they are information +necessary for the code-generator to generate correct code. The information +cannot be dropped. + +Extensions and capabilities are module level information. It would be possible +to encode them as named metadata attached to the module, which cannot be +dropped. That could work, except that we want to retain the connection between +the extensions and capabilities so that the backend can avoid generating them if +the function or type they are associated with are unused. +