Introduce CDataLayout & -fvk-use-c-layout (#8136)

Closes #8112. ~~The issue asks for a "C layout", but in this PR I use
the term "CPU layout" because this naming was pre-existing in the
codebase as `kCPULayoutRulesImpl_`. The primary purpose of this layout
is to match CPU-side struct definitions with the shader side. I'm open
to better naming suggestions, though.~~

Edit: switched back to using `CDataLayout` & `-fvk-use-c-layout`, as the
CPU target depends on the object layout rules of existing CPU layout
rules, but they're incompatible with actual shaders. So a new
`kCLayoutRulesImpl_` was needed anyway.

---------

Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com>

2 files changed, 10 insertions, 2 deletions

diff --git a/docs/command-line-slangc-reference.md b/docs/command-line-slangc-reference.md
index cf858a54c..36947d7b4 100644
--- a/docs/command-line-slangc-reference.md
+++ b/docs/command-line-slangc-reference.md
@@ -474,6 +474,11 @@ Make data accessed through ConstantBuffer, ParameterBlock, StructuredBuffer, Byt
 Pack members using FXCs member packing rules when targeting GLSL or SPIRV. 
 
 
+<a id="fvk-use-c-layout"></a>
+### -fvk-use-c-layout
+Make data accessed through ConstantBuffer, ParameterBlock, StructuredBuffer, ByteAddressBuffer and general pointers follow the C/C++ structure layout rules when targeting SPIRV. 
+
+
 <a id="fvk-b-shift"></a>
 ### -fvk-b-shift, -fvk-s-shift, -fvk-t-shift, -fvk-u-shift
 
diff --git a/docs/user-guide/a2-01-spirv-target-specific.md b/docs/user-guide/a2-01-spirv-target-specific.md
index 899fb39fd..c560297f7 100644
--- a/docs/user-guide/a2-01-spirv-target-specific.md
+++ b/docs/user-guide/a2-01-spirv-target-specific.md
@@ -192,9 +192,9 @@ StructuredBuffer and ByteAddressBuffer are translated to a shader storage buffer
 RWStructuredBuffer and RWByteAddressBuffer are translated to a shader storage buffer with `read-write` access.
 RasterizerOrderedStructuredBuffer and RasterizerOrderedByteAddressBuffer will use an extension, `SPV_EXT_fragment_shader_interlock`.
 
-If you need to apply a different buffer layout for individual `ConstantBuffer` or `StructuredBuffer`, you can specify the layout as a second generic argument. E.g., `ConstantBuffer<T, Std430DataLayout>`, `StructuredBuffer<T, Std140DataLayout>`, `StructuredBuffer<T, Std430DataLayout>` or `StructuredBuffer<T, ScalarDataLayout>`.
+If you need to apply a different buffer layout for individual `ConstantBuffer` or `StructuredBuffer`, you can specify the layout as a second generic argument. E.g., `ConstantBuffer<T, Std430DataLayout>`, `StructuredBuffer<T, Std140DataLayout>`, `StructuredBuffer<T, Std430DataLayout>`, `StructuredBuffer<T, ScalarDataLayout>` or `StructuredBuffer<T, CDataLayout>`.
 
-Note that there are compiler options, "-fvk-use-scalar-layout" / "-force-glsl-scalar-layout" and "-fvk-use-dx-layout".
+Note that there are compiler options, "-fvk-use-scalar-layout" / "-force-glsl-scalar-layout", "-fvk-use-dx-layout" and "-fvk-use-c-layout".
 These options do the same but they are applied globally.
 
 
@@ -454,6 +454,9 @@ Use std430 layout instead of D3D buffer layout for raw buffer load/stores.
 ### -fvk-use-dx-layout
 Pack members using FXCs member packing rules when targeting GLSL or SPIRV.
 
+### -fvk-use-c-layout
+Make data accessed through ConstantBuffer, ParameterBlock, StructuredBuffer, ByteAddressBuffer and general pointers follow the C/C++ structure layout rules when targeting SPIRV.
+
 ### -fvk-use-entrypoint-name
 Uses the entrypoint name from the source instead of 'main' in the spirv output.