Skip to content

Conversation

@MrSidims
Copy link
Contributor

@MrSidims MrSidims commented Dec 28, 2022

It was implemented via new decoration, which is not correct. Instead it should be Function Parameter Attribute decoration.

In this commit starts fixing this in step-by-step manner.

This step only adds reverse translation to be reused later by SPIR-V consumers.

Link to spec: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/INTEL/SPV_INTEL_runtime_aligned.asciidoc

Signed-off-by: Sidorov, Dmitry [email protected]

It was implemented via new decoration, which is not correct.
Instead it should be Function Parameter Attribute decoration.

In this commit starts fixing this in step-by-step manner.

Signed-off-by: Sidorov, Dmitry <[email protected]>
@MrSidims
Copy link
Contributor Author

MrSidims commented Feb 9, 2023

@broxigarchen may I ask you to take a look?

@MrSidims
Copy link
Contributor Author

Copy link
Contributor

@vmaksimo vmaksimo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only from the code I understood that somehow we want to save the non-conformant implementation for now. Please update the description about what this step do. Also the link to the spec could be useful.

Am I right that test/transcoding/SPV_INTEL_runtime_aligned/RuntimeAligned.ll is not changed for now because we preserve the old implementation?

mapValue(BA, &(*I));
setName(&(*I), BA);
BA->foreachAttr([&](SPIRVFuncParamAttrKind Kind) {
// Skip this function parameter attribute as it will translated among
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, why wasn't it skipped before?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it wasn't a function parameter attribute (since it was implemented incorrectly)

@tiwaria1
Copy link
Contributor

Viktoria this is the spec doc: https://github.com/KhronosGroup/SPIRV-Registry/blob/main/extensions/INTEL/SPV_INTEL_runtime_aligned.asciidoc

Yes it should be function parameter attribute as per the spec

@tiwaria1
Copy link
Contributor

Hey Dmitry, what did this look like in IR after reverse-translation before this change? What will the IR be after this change? (I am guessing kernel parameter attribute?)

@MrSidims
Copy link
Contributor Author

Hey Dmitry, what did this look like in IR after reverse-translation before this change? What will the IR be after this change? (I am guessing kernel parameter attribute?)

@tiwaria1 It remains to be the same - a function metadata looking like:
!kernel_arg_runtime_aligned !N
!N = !{i1 true, i1 false, i1 true, i1 false, i1 false}
(see both CHECK-LLVM in the test in this PR and https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/main/test/extensions/INTEL/SPV_INTEL_runtime_aligned/RuntimeAligned.ll for reference

@MrSidims
Copy link
Contributor Author

Only from the code I understood that somehow we want to save the non-conformant implementation for now. Please update the description about what this step do. Also the link to the spec could be useful.

Am I right that test/transcoding/SPV_INTEL_runtime_aligned/RuntimeAligned.ll is not changed for now because we preserve the old implementation?

Added in the description. Yeap, the test is unchanged intentionally

@tiwaria1
Copy link
Contributor

Hey Dmitry, what did this look like in IR after reverse-translation before this change? What will the IR be after this change? (I am guessing kernel parameter attribute?)

@tiwaria1 It remains to be the same - a function metadata looking like: !kernel_arg_runtime_aligned !N !N = !{i1 true, i1 false, i1 true, i1 false, i1 false} (see both CHECK-LLVM in the test in this PR and https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/main/test/extensions/INTEL/SPV_INTEL_runtime_aligned/RuntimeAligned.ll for reference

Thanks, I asked to understand if FPGA backend would need to be updated after this fix to handle IR changes. Looks like it will not be needed.

BF->foreachArgument([&](SPIRVFunctionParameter *Arg) {
if (Arg->getType()->isTypePointer() &&
if (Arg->hasAttr(FunctionParameterAttributeRuntimeAlignedINTEL) ||
Arg->hasDecorate(internal::DecorationRuntimeAlignedINTEL)) {
Copy link
Contributor

@broxigarchen broxigarchen Mar 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we finally will remove this line
"Arg->hasDecorate(internal::DecorationRuntimeAlignedINTEL)"
right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I believe that is the intention - but only after consumers are ready to work with the correct implementation.

@broxigarchen
Copy link
Contributor

Sorry I guess your previous email get buried in my mail box and I just saw it now.

PR looks good to me. I guess the SPIRV consumer might need to merge the patch later after it's finalized. Just curious why we need to do this step by step?

Arg->hasDecorate(internal::DecorationRuntimeAlignedINTEL)) {
DecorationFound = true;
RuntimeAlignedFound = true;
ValueVec.push_back(ForeachFnArg(Arg));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ForeachFnArg seems unnecessary here. We can just create a ConstantInt with 1 and push it here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

case FunctionParameterAttributeNoCapture:
case FunctionParameterAttributeNoWrite:
case FunctionParameterAttributeNoReadWrite:
case FunctionParameterAttributeRuntimeAlignedINTEL:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this change will be useful when SPIRVWriter.cpp is updated.

RuntimeAlignedFound = true;
ValueVec.push_back(ForeachFnArg(Arg));
} else {
llvm::Metadata *DefaultNode = ConstantAsMetadata::get(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One nit: Instead of creating DefaultNode for each Argument, we can create a single static global DefaultNode and push it when required.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess no need to have it as a global, moved it out of lambda to have it initialized only once in the function.

Copy link
Contributor

@asudarsa asudarsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Few nits. Are not PR blocking.

@MrSidims
Copy link
Contributor Author

Just curious why we need to do this step by step?

Without consumers update such SPIR-V changes will result in a missing feature. And once it's updated - it takes time until new driver is being propagated in different CIs (and SPIR-V generator change might reach CI at this point). Also I don't have much control over every SPIR-V consumer, hence prefer to go with conservative approach anyway.

@asudarsa
Copy link
Contributor

Closing and reopening to run tests.

@asudarsa asudarsa closed this Feb 13, 2024
@asudarsa asudarsa reopened this Feb 13, 2024
@asudarsa
Copy link
Contributor

Hi @MrSidims,

Is this change ready to be merged? Also, IIUC, the forward translation is the next and final step in this effort?

Thanks

@vmaksimo vmaksimo requested a review from asudarsa May 23, 2024 11:11
@@ -0,0 +1,68 @@
; RUN: llvm-spirv -spirv-text -r %s -o %t.bc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a blocker for this PR. Going forward, it will be great if we can introduce such .spt tests by generating them using the spirv-dis tool which generates a more readable file.

Thanks

Copy link
Contributor

@asudarsa asudarsa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Translator change Looks good. Thanks

@vmaksimo vmaksimo requested a review from broxigarchen June 25, 2024 10:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants