[llvm] [Coro] Amortize debug info processing cost in CoroSplit (PR #109032)

Felipe de Azevedo Piovezan via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 24 07:14:31 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,
----------------
felipepiovezan 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?

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.

Regarding what to do about this umbrella PR in the mean time, you have two options: leave this as is (with the understanding that it is not meant to be merged, merely serve as a reference for all the work left to do), or 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.

With all that stack, we'd never have to stack unmerged PRs on top of each other, does that make sense?

https://github.com/llvm/llvm-project/pull/109032


More information about the llvm-commits mailing list