[clang] Patch series to reapply #118734 and substantially improve it (PR #120534)

[Chandler Carruth via cfe-commits]

chandlerc wrote:

> > Is there any hope of upgrading MSVC? I know you were looking at that, but not sure what progress happened there.
> 
> I didn't go through with it and was hoping you would be able to find a work-around. I'll start talking to people to try and do a stop-gap update to a later version of VS2019 and let you know if/when we have deployed it. (I will be updating our upstream build bot as well at the same time).

What really baffles me is that LLVM itself should already be hitting this MSVC bug in serious ways starting with https://github.com/llvm/llvm-project/commit/381405fafe9d48d29c777e7680902d0943834859

That commit removed the only real workaround I know of from a *much* larger string table in the core of LLVM. What I can't figure out is why that string table compiles successfully but these don't. You all don't have any failing tests like `llvm/test/CodeGen/ARM/ldstrex.ll` or `llvm/test/Bitcode/arm-intrinsics.ll`?

Or any workaround patches to `llvm/lib/IR/Intrinsics.cpp`?

And line 18226-ish of the generated file `include/llvm/IR/IntrinsicImpl.inc`, you have `  98568, // llvm.arm.ldrex`? (Or if not that exact number, something larger than 64k...)

Mostly the above is for my curiosity to try and understand why the file in LLVM works despite all these in Clang not working....

I can basically revert parts of the above commit and make some other tablegen changes and I *should* be able to work around this if necessary. But it will make the above LLVM file and all these parts of Clang a bit slower to compile, sadly for all builds. So I'd like to avoid that if there is a reasonable way to upgrade. But if folks need to keep using this release series of MSVC, then we should somewhat systematically avoid risking this miscompile, even in the one place where it seems to work today.

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