[llvm] [StackColoring] Delete dead stack slots (PR #75351)

[Paul Kirth via llvm-commits]

ilovepi wrote:

Hi, our Linux CI is seing the following failure after this patch, and based on the assert, I'm pretty sure its related to this change.

```
clang-cl: llvm/include/llvm/CodeGen/MachineFrameInfo.h:530: int64_t llvm::MachineFrameInfo::getObjectOffset(int) const: Assertion `!isDeadObjectIndex(ObjectIdx) && "Getting frame offset for a dead object?"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /b/s/w/ir/x/w/llvm_build/./bin/clang-cl --target=x86_64-pc-windows-msvc /nologo -TP -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_GLIBCXX_ASSERTIONS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/orc/.. -I/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/orc/../../include -Xclang -ivfsoverlay -Xclang /b/s/w/ir/cache/windows_sdk/llvm-vfsoverlay.yaml /winsysroot /b/s/w/ir/cache/windows_sdk /Zc:inline /Zc:__cplusplus /Oi /bigobj /permissive- -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd5105 -wd4324 -w14062 -we4238 /Gw -no-canonical-prefixes /W4 -Wno-unused-parameter /Z7 /O2 /Ob1 -std:c++17 -MD -fno-builtin -fno-sanitize=safe-stack -fno-lto /Oy- /GS- /Zc:threadSafeInit- -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta /Z7 -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions /wd4146 /wd4291 /wd4391 /wd4722 /wd4800 -I/b/s/w/ir/x/w/llvm_build/include -I/b/s/w/ir/x/w/llvm-llvm-project/llvm/include /showIncludes /Focompiler-rt/lib/orc/CMakeFiles/RTOrc.x86_64.dir/coff_platform.cpp.obj /Fdcompiler-rt/lib/orc/CMakeFiles/RTOrc.x86_64.dir/ -c -- /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/orc/coff_platform.cpp
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module '/b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/lib/orc/coff_platform.cpp'.
4.	Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@"??$call at V?$Expected at V?$unordered_map at VExecutorAddr@__orc_rt@@V?$vector at VExecutorAddr@__orc_rt@@V?$allocator at VExecutorAddr@__orc_rt@@@std@@@std@@U?$hash at VExecutorAddr@__orc_rt@@@4 at U?$equal_to at VExecutorAddr@__orc_rt@@@4 at V?$allocator at U?$pair@$$CBVExecutorAddr at __orc_rt@@V?$vector at VExecutorAddr@__orc_rt@@V?$allocator at VExecutorAddr@__orc_rt@@@std@@@std@@@std@@@4@@std@@@__orc_rt@@VExecutorAddr at 2@@?$WrapperFunction@$$A6A?AV?$SPSExpected at V?$SPSSequence at V?$SPSTuple at VSPSExecutorAddr@__orc_rt@@V?$SPSSequence at VSPSExecutorAddr@__orc_rt@@@2@@__orc_rt@@@__orc_rt@@@__orc_rt@@VSPSExecutorAddr at 2@@Z at __orc_rt@@SA?AVError at 1@PEBXAEAV?$Expected at V?$unordered_map at VExecutorAddr@__orc_rt@@V?$vector at VExecutorAddr@__orc_rt@@V?$allocator at VExecutorAddr@__orc_rt@@@std@@@std@@U?$hash at VExecutorAddr@__orc_rt@@@4 at U?$equal_to at VExecutorAddr@__orc_rt@@@4 at V?$allocator at U?$pair@$$CBVExecutorAddr at __orc_rt@@V?$vector at VExecutorAddr@__orc_rt@@V?$allocator at VExecutorAddr@__orc_rt@@@std@@@std@@@std@@@4@@std@@@1 at AEBVExecutorAddr@1@@Z"'
#0 0x0000557e30175ef8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/b/s/w/ir/x/w/llvm_build/./bin/clang-cl+0x8643ef8)
clang-cl: error: clang frontend command failed with exit code 134 (use -v to see invocation)
Fuchsia clang version 18.0.0git (https://llvm.googlesource.com/llvm-project 70579c95bd12cb3035178f80a65718fd94cbf2ea)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: /b/s/w/ir/x/w/llvm_build/./bin
clang-cl: note: diagnostic msg: 
********************
```

[repro 2.zip](https://github.com/llvm/llvm-project/files/13688203/repro.2.zip)


If this is going to be hard to fix, can you revert this until its ready to reland?

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