[llvm] [Coro] Amortize debug info processing cost in CoroSplit (PR #109032)
Artem Pianykh via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 24 12:13:13 PDT 2024
================
@@ -205,6 +205,11 @@ void CloneAndPruneFunctionInto(Function *NewFunc, const Function *OldFunc,
const char *NameSuffix = "",
ClonedCodeInfo *CodeInfo = nullptr);
+/// Process debug information from function's subprogram attachment.
+DISubprogram *ProcessSubprogramAttachment(const Function &F,
----------------
artempyanykh wrote:
> So I think the best option here is to merge the two PRs that are approved (https://github.com/llvm/llvm-project/pull/112976 and https://github.com/llvm/llvm-project/pull/112948) . Both of those stand on their own and don't depend on each other, so it's fine to merge in w/e order, right?
That's right, yes.
> And then you can grab the third commit (or more, if the subsequent commits are also independent of each other) of this PR and open a new PR (or multiple PRs, if you did the () before), so it will look fine on top of main. My understanding is that the fourth commit depends on the third though.
After the first 2 are merged, extracting the third one in a separate PR is straightforward. With the rest of the stack there's quite a bit of sequencing, so we may need to rinse and repeat.
> rebase on top of main, which will get rid of the two-already merged commits and force push to your branch artempyanykh:fast-coro-upstream, which will mean this PR serves a reference of the work that's left to be merged, also with the understand that we're not merging it
+1 to this. I was planning to keep rebasing this stack anyway to make sure things keep working end-to-end while the chunks are being extracted and merged.
> By the way, do you have commit access?
No, not sure what the process for this is. Why?
https://github.com/llvm/llvm-project/pull/109032
More information about the llvm-commits
mailing list