Differential D75870 Diff 249210 mlir/include/mlir/Dialect/SPIRV/Passes.h

Changeset View

Standalone View

mlir/include/mlir/Dialect/SPIRV/Passes.h

	Show All 20 Lines
	class ModuleOp;			class ModuleOp;
	/// Creates a module pass that converts composite types used by objects in the			/// Creates a module pass that converts composite types used by objects in the
	/// StorageBuffer, PhysicalStorageBuffer, Uniform, and PushConstant storage			/// StorageBuffer, PhysicalStorageBuffer, Uniform, and PushConstant storage
	/// classes with layout information.			/// classes with layout information.
	/// Right now this pass only supports Vulkan layout rules.			/// Right now this pass only supports Vulkan layout rules.
	std::unique_ptr<OpPassBase<mlir::ModuleOp>>			std::unique_ptr<OpPassBase<mlir::ModuleOp>>
	createDecorateSPIRVCompositeTypeLayoutPass();			createDecorateSPIRVCompositeTypeLayoutPass();

	/// Creates a module pass that lowers the ABI attributes specified during SPIR-V			/// Creates an operation pass that deduces and attaches the minimal version/
	/// Lowering. Specifically,			/// capabilities/extensions requirements for spv.module ops.
	/// 1) Creates the global variables for arguments of entry point function using			/// For each spv.module op, this pass requires a `spv.target_env` attribute on
	/// the specification in the ABI attributes for each argument.			/// it or an enclosing module-like op to drive the deduction. The reason is
	/// 2) Inserts the EntryPointOp and the ExecutionModeOp for entry point			/// that an op can be enabled by multiple extensions/capabilities. So we need
	/// functions using the specification in the EntryPointAttr.			/// to know which one to pick. `spv.target_env` gives the hard limit as for
				/// what the target environment can support; this pass deduces what are
				/// actually needed for a specific spv.module op.
				std::unique_ptr<OpPassBase<spirv::ModuleOp>>
				mravishankarUnsubmitted Done Reply Inline Actions This seems to assume that there is a "linear" order of capabilities and extensions. Is that the case? Also, is there a way to have a "Base" limit you can start with? It can be the most lenient or the least lenient set mravishankar: This seems to assume that there is a "linear" order of capabilities and extensions. Is that the…
				antiagainstAuthorUnsubmitted Done Reply Inline Actions For an op, there can exists multiple capabilities to enable it. E.g., `OpGroupNonUniformIAdd` can be enabled by any of [GroupNonUniformArithmetic, GroupNonUniformClustered, GroupNonUniformPartitionedNV]. It's a set (although under the hood we indeed search linearly but that's implementation detail). Any one of them allowed by the target it should be fine and we'll pick that one. It's hard to find a more "general" or well supported one that's also a moving target given new hardware coming up and existing ones updated. antiagainst: For an op, there can exists multiple capabilities to enable it. E.g., `OpGroupNonUniformIAdd`…
				createUpdateVersionCapabilityExtensionPass();

				/// Creates an operation pass that lowers the ABI attributes specified during
				/// SPIR-V Lowering. Specifically,
				/// 1. Creates the global variables for arguments of entry point function using
				/// the specification in the `spv.interface_var_abi` attribute for each
				/// argument.
				/// 2. Inserts the EntryPointOp and the ExecutionModeOp for entry point
				/// functions using the specification in the `spv.entry_point_abi` attribute.
	std::unique_ptr<OpPassBase<spirv::ModuleOp>> createLowerABIAttributesPass();			std::unique_ptr<OpPassBase<spirv::ModuleOp>> createLowerABIAttributesPass();

	} // namespace spirv			} // namespace spirv
	} // namespace mlir			} // namespace mlir

	#endif // MLIR_DIALECT_SPIRV_PASSES_H_			#endif // MLIR_DIALECT_SPIRV_PASSES_H_