-
Notifications
You must be signed in to change notification settings - Fork 14.4k
[GlobalOpt] Update debug info when changing CC to Fast #144303
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
Open
momo5502
wants to merge
1
commit into
llvm:main
Choose a base branch
from
momo5502:main
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a bit brittle, if other targets had other calling convention choices - perhaps this logic should go wherever the CC is determined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. However, I think the mapping for fastcc is determined by a table definition for each architecture. I feel like integrating this there is not easily feasible.
Do you have a recommendation on how this could be done better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you point to the table definition, we/someone could take a look to see how practical it is.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The decision how FastCC is being lowered happens here:
llvm-project/llvm/lib/Target/X86/X86CallingConv.td
Line 1062 in ec25a05
Here is where the dwarf CC is translated to the CodeView format:
llvm-project/llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
Line 2008 in ec25a05
I feel like the reason this issue arises in the first place is the redundancy for calling convention specifications: the information is stored in the function, as well as the debug info.
What would also work would be a pseudo dwarf calling convention for fastCC that can then be mapped onto the real CC for each respective platform. However, I assume that for most platforms this is just the normal calling convention, which is why this approach seemed to cause the least overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps @zmodem has some thoughts on the PDB side of things, and @nikic has some thoughts on the broader LLVM architectural issue.
Yeah, I'd be open to the right direction being each architecture having a mapping from their real CCs to the DWARF CC they want to use for them, and removing the CC from the LLVM IR debug info metadata.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No PDB specific thoughts really, but it does sound redundant to store the calling convention in the debug info metadata as well (and error prone as it needs to stay in sync).
When we lower the debug metadata (or translate it to codeview), do we have an easy way to get to the llvm::Function? If so it sounds like we should just get the calling convention from there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do - the subprogram data is attached to the llvm::Function (so, technically, you could be looking at a subprogram without knowing what function it came from, but that's fixable)
I guess in the case where a DWARF function declaration is emitted with no associated LLVM IR, it might be a problem - in theory we could/may need to still carry a calling convention down through the debug info metadata to handle cases like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't go the route of dropping it from the metadata, maybe the verifier could check for Function/metadata calling convention consistency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - I'm not 100% sure we carry CC on declarations, so someone'd have to check that/see if we need it anyway. And if we do, yeah, checking for consistency would be good - and maybe the metadata would/could carry the same type of CC as the IR, rather than the debug info one - and then only convert from real CC to DWARF CC at the backend.