support specialization constant sized array #6871

kaizhangNV · 2025-04-21T17:34:03Z

Goal of this PR
We want to support an array whose size can be specialization constant for shared/global variable e.g.

layout (constant_id = 0) const uint BLOCK_SIZE = 64;
shared float buf_a[(BLOCK_SIZE + 5) * 4];

Overview of the solution:

During IndexExpr check, we will loose the restriction to allow SpecConst passing, but the size parameter will not be a constant value because it cannot be folded into a constant, instead it will be an expression that will result in SpecConst value.
During IR lowering, we will still lower the array to sized array, but the size will not be an int value, instead we will lower it to a global constant, the initial value will be the IR inst lowering from the specConst expression from above step, and we will decorate this global constant variable with kIROp_SpecializationConstantOpDecoration.
During spirv emit stage, we will allow emit global constant variable only when it has the decoration of kIROp_SpecializationConstantOpDecoration.
We have to implement new logic to emit OpSpecConstantOp, the existing emit logic doesn't support emitting OpSpecConstantOp, especially this op can embed arithmetic operation at global scope, where we can only emit arithmetic instruct at local. But there are only few instructs we need to support.

Overview of the solution:
Note: This PR is not aimed to support all possible opcodes supported by OpSpecConstantOp, only those 32-bit integer opcode, because only those types can be used for array size. For those untypical usage, we can leave in the future to extend, current emit struct should be easy to extend.

csyonghe · 2025-04-21T18:39:38Z

My thinking is that we should lower such array as a sized array. Why is that not possible?

getTypeTags function should report such array types as unsized, and that should be everything we need...

csyonghe · 2025-04-21T18:42:32Z

The size of the array should be folded into a GenericParamIntVal which wraps a declref to the spec const var, similar to how we handle linktime array sizes.

The GenericParamIntVal used to mean the IntVal is from a generic int parameter, however, that later got extended to also represent int values from a link time constant. It really should have been renamed to DeclRefIntVal.

kaizhangNV · 2025-04-21T18:45:07Z

My thinking is that we should lower such array as a sized array. Why is that not possible?

It's not impossible. I made this choice is because by lower to unsized array could potentially avoid any potential checks during type checking and IR legalization pass, so that could make this PR simpler, while the two decisions (unsized array vs sized array) should be equally feasible. But maybe I'm overthinking about the cost.

csyonghe · 2025-04-21T18:45:46Z

I don't think there are any checks after IR lowering, and we should be fine there.

kaizhangNV · 2025-04-21T18:51:29Z

OK, I can change it to sized array, it should be very small change.

But the problem still exists, take this example in the description

<arraySize> = (BLOCK_SIZE + 5) * 4

we want to emit this to something like this:

%1 = OpSpecConstantOp Add BLOCK_SIZE 5
%2 = OpSpecConstantOp MIUL %1 4

our currently emit logic won't let me do that. So I guess I will have to implement the logic in emit-spirv.

csyonghe · 2025-04-21T19:46:35Z

Yeah, we will need to find a way to emit this, independent from how we represent this in the type system or IR.

…able

add one more unit test

csyonghe

I don't think you need to make any changes to ir lowering or mangling at all, if we reuse/rename the existing GenericParamIntVal to point to speicalization constant decls.

We just need to insert the right spirv legalization logic to turn the intermediate expressions (e.g. opAdd etc.) into its own specConst, before it is used in array sizes.

csyonghe · 2025-05-07T23:46:23Z

source/slang/slang-ast-builder.cpp

    if (elementCount->getType() != getIntType())
    {
        // Canonicalize constant elementCount to int.
        if (auto elementCountConstantInt = as<ConstantIntVal>(elementCount))
        {
            elementCount = getIntVal(getIntType(), elementCountConstantInt->getValue());
        }
+        else if (auto elementCountSpecConstInt = as<SpecializationConstantIntVal>(elementCount))
+        {
+            elementCount = getSpecConstIntVal(getIntType(), elementCountSpecConstInt->getValue());


I don't think we need this case. The else branch should handle the specializeation constant case just fine.

csyonghe · 2025-05-07T23:48:07Z

source/slang/slang-ast-builder.h

@@ -524,6 +529,10 @@ class ASTBuilder : public RefObject
    PtrTypeBase* getPtrType(Type* valueType, AddressSpace addrSpace, char const* ptrTypeName);

    ArrayExpressionType* getArrayType(Type* elementType, IntVal* elementCount);
+    ArrayExpressionType* getArrayType(


we shouldn't need this.

csyonghe · 2025-05-07T23:48:19Z

source/slang/slang-ast-builder.h

@@ -386,6 +386,11 @@ class ASTBuilder : public RefObject
        return getOrCreate<ConstantIntVal>(type, value);
    }

+    SpecializationConstantIntVal* getSpecConstIntVal(Type* type, Val* specConstVal)


as we discussed, we just need getDeclRefIntVal.

csyonghe · 2025-05-07T23:52:51Z

source/slang/slang-check-expr.cpp

        else
        {
            allConst = false;
        }
    }

+    if (allConst && hasSpecializationConstant)
+    {
+        // If the expression contains a specialization constant, we are not able to constant fold


If we don't add the hasSpecializationConstant change here, and just have everything processed the same way as if a specialization constant is a generic value parameter, would anything go wrong?

I feel like things will run just fine if we undo all the changes to this function.

csyonghe · 2025-05-07T23:54:30Z

source/slang/slang-check-expr.cpp

@@ -1974,7 +2006,9 @@ IntVal* SemanticsVisitor::tryConstantFoldDeclRef(
    // if they're marked `const`.
    if (decl->hasModifier<SpecializationConstantAttribute>() ||
        decl->hasModifier<VkConstantIdAttribute>())
-        return nullptr;
+    {


also need kind == ConstantFoldingKind::SpecializationConstantTime

csyonghe · 2025-05-07T23:56:03Z

source/slang/slang-check-expr.cpp

+            if (auto specConstElementCount = as<SpecializationConstantIntVal>(elementCount))
+            {
+                // We need to check if the specialization constant has valid specConst expression
+                if (!specConstElementCount->getValue())


How can we ever run into this case? SpecializationConstantIntVal either exists and points to a valid var decl, or it doesn't. SpecializationConstantIntVal should be holding a declref to the var decl.

csyonghe · 2025-05-07T23:58:47Z

source/slang/slang-ast-val.h

+    Val* getValue()
+    {
+        Val* val = getOperand(1);
+        if (!as<FuncCallIntVal>(val) && !as<DeclRefBase>(val))


SpecializationConstantIntVal should just be wrapping a declref, val here shouldn't be a FuncCallIntVal.

csyonghe · 2025-05-07T23:59:48Z

source/slang/slang-lower-to-ir.cpp

@@ -492,6 +492,8 @@ struct SharedIRGenContext
    Dictionary<SourceFile*, IRInst*> mapSourceFileToDebugSourceInst;
    Dictionary<String, IRInst*> mapSourcePathToDebugSourceInst;

+    Dictionary<SpecializationConstantIntVal*, IRInst*> mapSpecConstValToIRInst;


I think we don't need this mapping, if we use the existing GenericParamIntVal to refer to specialization constants.

csyonghe · 2025-05-08T00:00:23Z

source/slang/slang-lower-to-ir.cpp

@@ -2056,7 +2074,38 @@ struct ValLoweringVisitor : ValVisitor<ValLoweringVisitor, LoweredValInfo, Lower
        auto elementType = lowerType(context, type->getElementType());
        if (!type->isUnsized())
        {
-            auto elementCount = lowerSimpleVal(context, type->getElementCount());
+            IRInst* elementCount = nullptr;
+            if (auto specConstIntVal = as<SpecializationConstantIntVal>(type->getElementCount()))


This isn't needed. The existing lowering logic for GenericParamIntVal should just work for specialization constants.

kaizhangNV requested a review from a team as a code owner April 21, 2025 17:34

kaizhangNV marked this pull request as draft April 21, 2025 17:34

kaizhangNV changed the title ~~support specialization constant sized array~~ WIP: support specialization constant sized array Apr 21, 2025

kaizhangNV added the pr: non-breaking PRs without breaking changes label Apr 21, 2025

kaizhangNV force-pushed the spec_const_arrSize branch 3 times, most recently from 8bf2a3d to 9c8ea34 Compare April 23, 2025 21:07

kaizhangNV added 12 commits May 7, 2025 09:24

support specialization constant sized array

e08ec81

fix warning

27f0b5f

format

0f13902

fix build error

882fa6a

Only enable specialization constant sized array in global/shared vari…

e96e0f2

…able

fix issue on getting array size

cc93869

only allow global variable to use specConst sized array

13ee19e

trying fix issue when there are multiple spacConst array declared

c801938

create SpecializationConstantIntVal to represent specConst array size

970cc64

update ir lowering

88ab8eb

add unit test

646d4bd

fix issue on getting array size in debugVar emit

7ecbadd

add one more unit test

kaizhangNV force-pushed the spec_const_arrSize branch from 9fe0c62 to 7ecbadd Compare May 7, 2025 17:07

kaizhangNV added 4 commits May 7, 2025 11:18

fix build error

958985f

cleanup

48618e8

cleanup

41cb1c9

ir lower refactor

d506881

kaizhangNV marked this pull request as ready for review May 7, 2025 20:17

kaizhangNV added 2 commits May 7, 2025 13:56

fix build error

f2c3f0d

format

0465db4

kaizhangNV changed the title ~~WIP: support specialization constant sized array~~ support specialization constant sized array May 7, 2025

csyonghe reviewed May 8, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

support specialization constant sized array #6871

support specialization constant sized array #6871

kaizhangNV commented Apr 21, 2025 •

edited

Loading

csyonghe commented Apr 21, 2025

csyonghe commented Apr 21, 2025

kaizhangNV commented Apr 21, 2025

csyonghe commented Apr 21, 2025

kaizhangNV commented Apr 21, 2025

csyonghe commented Apr 21, 2025

csyonghe left a comment

csyonghe May 7, 2025

csyonghe May 7, 2025

csyonghe May 7, 2025

csyonghe May 7, 2025

csyonghe May 7, 2025

csyonghe May 7, 2025

csyonghe May 7, 2025

csyonghe May 7, 2025

csyonghe May 8, 2025

support specialization constant sized array #6871

Are you sure you want to change the base?

support specialization constant sized array #6871

Conversation

kaizhangNV commented Apr 21, 2025 • edited Loading

csyonghe commented Apr 21, 2025

csyonghe commented Apr 21, 2025

kaizhangNV commented Apr 21, 2025

csyonghe commented Apr 21, 2025

kaizhangNV commented Apr 21, 2025

csyonghe commented Apr 21, 2025

csyonghe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaizhangNV commented Apr 21, 2025 •

edited

Loading