-
Notifications
You must be signed in to change notification settings - Fork 11.8k
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
[NVPTX] Incorrect alignment in call prototype for 'sprintf' function #100055
Labels
Milestone
Comments
@Artem-B Any ideas? I've disabled |
I have made a smaller reproducer https://godbolt.org/z/G7da6s6Yz. This will give the same error,
If the alignment is modified to be |
jhuber6
added a commit
to jhuber6/llvm-project
that referenced
this issue
Jul 23, 2024
Summary: The NVPTX backend optimizes the ABI for functions that are internal, however, this is not legal for indirect call prototypes. Previously, we would modify the ABI on an aggregate byval type passed to an indirect call prototype, which would make PTXAS error. This patch just passes the function as a nullptr to force strict ABI compliance without modification in the helper function. Fixes llvm#100055
jhuber6
added a commit
to jhuber6/llvm-project
that referenced
this issue
Jul 23, 2024
Summary: The NVPTX backend optimizes the ABI for functions that are internal, however, this is not legal for indirect call prototypes. Previously, we would modify the ABI on an aggregate byval type passed to an indirect call prototype, which would make PTXAS error. This patch just passes the function as a nullptr to force strict ABI compliance without modification in the helper function. Fixes llvm#100055
/cherry-pick e0649a5 |
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Jul 23, 2024
…vm#100131) Summary: The NVPTX backend optimizes the ABI for functions that are internal, however, this is not legal for indirect call prototypes. Previously, we would modify the ABI on an aggregate byval type passed to an indirect call prototype, which would make PTXAS error. This patch just passes the function as a nullptr to force strict ABI compliance without modification in the helper function. Fixes llvm#100055 (cherry picked from commit e0649a5)
/pull-request #100174 |
tru
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Jul 24, 2024
…vm#100131) Summary: The NVPTX backend optimizes the ABI for functions that are internal, however, this is not legal for indirect call prototypes. Previously, we would modify the ABI on an aggregate byval type passed to an indirect call prototype, which would make PTXAS error. This patch just passes the function as a nullptr to force strict ABI compliance without modification in the helper function. Fixes llvm#100055 (cherry picked from commit e0649a5)
yuxuanchen1997
pushed a commit
that referenced
this issue
Jul 25, 2024
…00131) Summary: The NVPTX backend optimizes the ABI for functions that are internal, however, this is not legal for indirect call prototypes. Previously, we would modify the ABI on an aggregate byval type passed to an indirect call prototype, which would make PTXAS error. This patch just passes the function as a nullptr to force strict ABI compliance without modification in the helper function. Fixes #100055 Test Plan: Reviewers: Subscribers: Tasks: Tags: Differential Revision: https://phabricator.intern.facebook.com/D60251110
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The NVPTX backend currently emits the incorrect alignment when trying to compile the
sprintf
function with LTO. It will emit errors like the following:Looking at the IR in https://godbolt.org/z/n9nK6ddxb I noticed that many of these
_
function calls come from the main implementation. If this function is internalized, then these calls get an incorrect alignment of16
as in the following:If I make the indirect call instead have an alignment of
8
, then it works just fine, i.e. This also happens if I manually remove theinternal
keyword from the function and thus make it.visible
.Any clue why this would cause issues? Since this is an indirect call it's not like there's a set prototype we need to adhere to. And I don't see why making the function
.visible
or not makes the alignment correct.The text was updated successfully, but these errors were encountered: