[StackColoring] Reliance on DCE for removing fixed-stack LIFETIME Markers

[tobias-stadler]

StackColoring fails to remove fixed-stack lifetime markers. The only reason this doesn't cause crashes (e.g. in PEI) is that DeadMachineInstructionElimination runs shortly after StackColoring, considers lifetime markers dead and thus removes any remaining markers before any passes run that can't handle them. This seems a little bit sketchy and I couldn't find any mention of this being intended (or an existing issue). It makes sense that fixed-stack lifetime markers aren't considered in StackColoring, but it seems like they should at least be removed.

I discovered this while trying to unify GlobalISel's isTriviallyDead behavior with DeadMIElimination's isDead.

In my opinion, DeadMIElimination should not remove lifetime markers. If some backend ever wants to do a run of DeadMIElimination before StackColoring they will run into this issue.

Here is an example taken from CodeGen/X86/catchpad-lifetime.ll.
https://godbolt.org/z/o5orK8P8r
We can see that a LIFETIME_END marker survives StackColoring.

Root causes:

https://github.com/llvm/llvm-project/blob/08acc3f73b64bed578d18812a04015cb537c9c82/llvm/lib/CodeGen/StackColoring.cpp#L1195C2-L1199C18

This returns early without removing markers even if fixed-stack lifetime markers exist.

https://github.com/llvm/llvm-project/blob/08acc3f73b64bed578d18812a04015cb537c9c82/llvm/lib/CodeGen/StackColoring.cpp#L654C1-L658C20

This skips markers referencing fixed-stack objects, so they are never added to the Markers list and thus never removed.

Is this intended/known behavior and if not how should we go about fixing this?
Should StackColoring guarantee to always remove all lifetime markers?

(Not sure who is invested in StackColoring, from the git log: @nikic maybe)