[clang] [llvm] [llvm][clang] Allocate a new stack instead of spawning a new thread to get more stack space (PR #133173)

[Michael Spencer via llvm-commits]

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