Skip to content

Conversation

VyacheslavLevytskyy
Copy link
Contributor

@VyacheslavLevytskyy VyacheslavLevytskyy commented Feb 25, 2025

This PR fixes the issue with Khronos Translator incorrectly translating calls to builtins that returns a structure and generating incorrect extractvalue applied to a pointer. The PR is to fix the issue by preserving equivalence of newly inserted values with prior values of function return's type.

@@ -2269,12 +2270,18 @@ bool postProcessBuiltinReturningStruct(Function *F) {
NewF->setCallingConv(F->getCallingConv());
auto Args = getArguments(CI);
Args.insert(Args.begin(), A);
CallInst *NewCI = Builder.CreateCall(NewF, Args, CI->getName());
CallInst *NewCI = Builder.CreateCall(
NewF, Args, NewF->getReturnType()->isVoidTy() ? "" : CI->getName());
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we change Name argument to CreateCall? Neither the llvm-17 branch, nor your fix to the main branch contains this change

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've hit an error on the 18th LLVM version with test/builtin_returns_struct.spvasm -- given a newly inserted call spir_func void @_Z17__spirv_IAddCarryii(ptr sret(%structtype) %[[#Var:]] the code tried to use a non-empty name for the instruction and LLVM failed with an error. This check prevents this fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

More specifically, the error was due to an attempt to assign name to a void-typed instruction

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, understandable. Although, I don't get why we don't face this issue on the main branch or even on the llvm-19. Do you have any thoughts/observations?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a very good question actually. My observation is that Builder.CreateCall(NewF, Args, CI->getName()) has empty CI->getName() due to some differences in processing between branches. I'd say that we should port this backport finding and harden the main branch with this check NewF->getReturnType()->isVoidTy() ? "" : CI->getName() as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've added the same check for a void-typed instruction into the "Backport to 19" patch.

Copy link
Contributor

Choose a reason for hiding this comment

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

As #3027 was approved, should I assume, that this PR with the similar code is also approved by @vmaksimo

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@vmaksimo do you have any followup to the Name argument to CreateCall please?

Copy link
Contributor

Choose a reason for hiding this comment

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

@MrSidims actually I approved before this check was added.
That's still strange, but let's proceed with it.

@VyacheslavLevytskyy VyacheslavLevytskyy changed the title [Backport to 17] Fix incorrect translation of calls to a builtin that returns a structure [Backport to 17] Fix incorrect translation of calls to a builtin that returns a structure (#2722) Feb 25, 2025
@VyacheslavLevytskyy VyacheslavLevytskyy merged commit eccbadc into KhronosGroup:llvm_release_170 Feb 26, 2025
9 checks passed
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.

3 participants