LGTM

Just for note: it seems that skipping extracting lifetime.start when lifetime.end can't be lifted (in 2nd option) can again lead to miscompile as in https://reviews.llvm.org/D55967 (assume that markers for x and y in rhs are not lifted). It's safer to extract all lifetime.start markers referencing inputs to mark them all as simultaneously used, as in option (1).

In this example there are two possible entry points in region, so it can't be extracted (first block in region should dominate the others). Maybe there are better examples of issue?
As I understand, correct (but conservative) transformation is to move lifetime.start upwards to some dominator block. According to this, lifting lifetime.start before call must be right. Moving lifetime.end downwards to some post-dominator block is generally incorrect. The case when lifetime.end for the same value occured at every execution path doesn't seem very common, but placing lifetime.end after call gives more accurate information. The thing that is unclear fo me is how erasing all markers for input in case when lifetime.end can't be lifted helps stack coloring?
BTW, it seems there is no simple solution that doesn't reduce stack coloring opportunities in all cases (can't provide information to the caller whether lifetime.end for given value occured or not).

LGTM

Thank you! Could you please commit it? (I don't have access to do it)

Add assertion for the InsertPt
Remove DT construction from CodeExtractor tests
Simplify test

lgtm

LGTM

I'm concerned about skipping processing markers for outputs. Currently HotColdSplit and partial inlining do not outline function if number of outputs is not zero (by calling findInputsOutputs()), but this check is unreliable because there is some processing of region before extracting (splitReturnBlocks, splitPHINodesOfEntry, splitPHINodesOfExit) and input/output parameters can be changed (their number may become non-zero). So another question is why this check should be done at all (does it bypass some known problem?) Seems that CodeExtractor does not impose such restrictions.

Thank you! I don't have commit access, could you please submit it?

Fix issue when terminator instruction in predecessor is switch
Add unit test for PHIs with one incoming value from region

Fix comments style
Return assertion back
Verify function consistency before outlining