maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/test/Target/SPIRV/execution-mode.mlir

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

11 lines
329 B
MLIR
Raw Normal View History

Register a -test-spirv-roundtrip hook to mlir-translate This CL registers a new mlir-translate hook, -test-spirv-roundtrip, for testing SPIR-V serialization and deserialization round-trip. This CL also moves the existing -serialize-spirv and -deserialize-spirv hooks to one source file. PiperOrigin-RevId: 269659528
2019-09-18 05:47:55 +08:00
// RUN: mlir-translate -test-spirv-roundtrip %s | FileCheck %s
Add (de)serialization of EntryPointOp and ExecutionModeOp Since the serialization of EntryPointOp contains the name of the function as well, the function serialization emits the function name using OpName instruction, which is used during deserialization to get the correct function name. PiperOrigin-RevId: 259158784
2019-07-21 09:11:39 +08:00
[mlir][spirv] Use spv.vce in spv.module and wire up (de)serialization This commits changes the definition of spv.module to use the #spv.vce attribute for specifying (version, capabilities, extensions) triple so that we can have better API and custom assembly form. Since now we have proper modelling of the triple, (de)serialization is wired up to use them. With the new UpdateVCEPass, we don't need to manually specify the required extensions and capabilities anymore when creating a spv.module. One just need to call UpdateVCEPass before serialization to get the needed version/extensions/capabilities. Differential Revision: https://reviews.llvm.org/D75872
2020-03-12 04:04:25 +08:00
spv.module Logical GLSL450 requires #spv.vce<v1.0, [Shader], []> {
[mlir][spirv] Introduce spv.func Thus far we have been using builtin func op to model SPIR-V functions. It was because builtin func op used to have special treatment in various parts of the core codebase (e.g., pass pipelines, etc.) and it's easy to bootstrap the development of the SPIR-V dialect. But nowadays with general op concepts and region support we don't have such limitations and it's time to tighten the SPIR-V dialect for completeness. This commits introduces a spv.func op to properly model SPIR-V functions. Compared to builtin func op, it can provide the following benefits: * We can control the full op so we can integrate SPIR-V information bits (e.g., function control) in a more integrated way and define our own assembly form and enforcing better verification. * We can have a better dialect and library boundary. At the current moment only functions are modelled with an external op. With this change, all ops modelling SPIR-V concpets will be spv.* ops and registered to the SPIR-V dialect. * We don't need to special-case func op anymore when creating ConversionTarget declaring SPIR-V dialect as legal. This is quite important given we'll see more and more conversions in the future. In the process, bumps a few FuncOp methods to the FunctionLike trait. Differential Revision: https://reviews.llvm.org/D74226
2020-02-08 00:30:19 +08:00
spv.func @foo() -> () "None" {
Remove the wrapping function in SPIR-V (de)serialization Previously Module and Function are builtinn constructs in MLIR. Due to the structural requirements we must wrap the SPIR-V module inside a Function inside a Module. Now the requirement is lifted and we can remove the wrapping function! :) PiperOrigin-RevId: 264736051
2019-08-22 09:04:56 +08:00
spv.Return
Add (de)serialization of EntryPointOp and ExecutionModeOp Since the serialization of EntryPointOp contains the name of the function as well, the function serialization emits the function name using OpName instruction, which is used during deserialization to get the correct function name. PiperOrigin-RevId: 259158784
2019-07-21 09:11:39 +08:00
}
Remove the wrapping function in SPIR-V (de)serialization Previously Module and Function are builtinn constructs in MLIR. Due to the structural requirements we must wrap the SPIR-V module inside a Function inside a Module. Now the requirement is lifted and we can remove the wrapping function! :) PiperOrigin-RevId: 264736051
2019-08-22 09:04:56 +08:00
spv.EntryPoint "GLCompute" @foo
// CHECK: spv.ExecutionMode @foo "LocalSizeHint", 3, 4, 5
spv.ExecutionMode @foo "LocalSizeHint", 3, 4, 5
}