Issue 134119
Summary [SPIR-V] Emit an explicit layout for types that require it.
Labels backend:SPIR-V
Assignees s-perron
Reporter s-perron
    In SPIR-V, composite objects in the Uniform, PushConstant, PhysicalStorageBuffer, and the StorageBuffer storage class require an explicit layout. Since these storage classes are shader specific, no type has required an explicit layout until now.

I will try to implement this during ISel as follows:

1. When translating a Type to a SPIRVType:
  a. If it is not a pointer type, then generate a type without an explicit layout.
  b. If is is a pointer type, then generate the pointee type for the pointer with an explicit layout if it is required.
2. Fix the invalid code generated at the transition between memory and registers.
  a. For a load from memory, the result type will not have an explicit layout, but the memory will. In SPIR-V, 
      this is invalid because they are different types. This will be fixed by modifying the result type so it has an explicit layout. Then an OpCopyLogical will be applied to the result to get an object of the original result type.
  b. The same problem can happen with stores. In this case, the OpCopyLogical will be applied to the object operand. 

This change will require a significant change to the type system in the backend. 


The necessary changes I see at this type:

- [ ] Modify the interface to the global registery to get a pointer so that it takes a `Type*` for the pointee type instead of a `SPIRVType*`. This will allow all logic to decide when to create the explicit layout in a single place.
- [ ] Update the SPIRVIRMapping so that is knows if the SPIRVType was suppose to have an explicit layout.
- [ ] Generate an explicit layout for pointee types when required.
- [ ] Fix up type mismatches by adding OpCopyLogical when necessary.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to