Bigcheese wrote: > If split stacks are negatively impacting profiling, debugging, or other > compiler development tasks, I have to ask, have we considered optimizing > clang stack usage?
The issue is we will always have this problem with implicitly built modules. It's naturally recursive as we need a totally separate compiler instance. I think it would be good to reduce stack usage, and there are likely some easy wins here, but I don't know if it's worth significantly changing the code to remove recursion and the need for this entirely. It's a pretty natural way to handle the recursive parts of C++. > I'm a bit concerned about this changing behavior only for Apple platforms; > that's a different folks doing triage really need to understand. I don't think it's really that big of a difference. It just changes what stack traces look like, and they will contain `runOnNewStack` where the stack split occurs. > Doesn't Linux also support this functionality, so we'd at least get the > coverage on more than one platform? (Linux could be done in a follow-up, but > I'm mostly worried we'll only ever implement this for Apple at which point I > question whether the extra complexity is something the community should > maintain or not.) Linux does support running code like this, but Linux also means hundreds of distros. There is likely a combination of unwinder and debugger that support this, but I wouldn't turn it on by default unless that set is in very common use. I'm fine with adding a CMake flag that enables this on at least Linux AArch64. It will always run correctly, just not all tools will handle the back trace. Same thing for Windows, although there I have no information on if the MS tools support it. I believe this is also easy to do on x86-64, but a lot harder on 32bit x86. https://github.com/llvm/llvm-project/pull/133173 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
