Thanks to visit codestin.com
Credit goes to github.com

Skip to content

WIP: support specialization constant sized array #6871

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

kaizhangNV
Copy link
Contributor

@kaizhangNV kaizhangNV commented Apr 21, 2025

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.

@kaizhangNV kaizhangNV requested a review from a team as a code owner April 21, 2025 17:34
@kaizhangNV kaizhangNV marked this pull request as draft April 21, 2025 17:34
@kaizhangNV kaizhangNV changed the title support specialization constant sized array WIP: support specialization constant sized array Apr 21, 2025
@kaizhangNV kaizhangNV added the pr: non-breaking PRs without breaking changes label Apr 21, 2025
@csyonghe
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Collaborator

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

@kaizhangNV
Copy link
Contributor Author

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr: non-breaking PRs without breaking changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants