BTW, we can completely delete tied dead,undef pair. But additional complexity might not worth it.

Add test case;

LGTM

LGTM.
Though, I don't see much point in having it :)

LGTM

LGTM

LGTM

LGTM

The way I read the lang ref this is intentional. Not to say one should not define what it means for vectors of pointers and then allow it. I feel align is not the only one missing for them though.
You want to give it a try?

Address review comments

I wonder if align attribute is legal for vectors of pointers?
This is allowed:

define align 8 i32* @test_scalar(i32* %in) {
  ret i32* %in
}

but this is not:

define align 8 <4 x i32*> @test_vector(<4 x i32*> %in) {
  ret <4 x i32*> %in
}

Is it intentional behavior or just has been overlooked?

Add local asserts

Update statepoint MI description, provide link to it at parseStatepointOperands;
Fix style issues;

Address most review comments:

• add documentation to API
• factor out some code to separate function
• fix test instead of XFAILing it

Rebase on tip and use newly added API;
Slightly change GC pointer operand lowering;

Thanks, it reads much better for me now.
Looks good.

Can we come up with better format for gc pointer map (base/derived)?
I wish it were possible to have it in separate psude instruction glued with statepoint. Unfortunately, that seems impossible now.

Looks good for me.
The only thing that worries me is shouldn't we have broader audience since we're changing 'global' APIs?

All pieces has been landed, so closing it.
Unfortunately, final result (e.g. ISEL part) diverged quite a bit from this, but idea at large has not changed

LGTM with couple nits inline

https://reviews.llvm.org/rGd21ce4082181

%10:gr64 = MOV64rm killed %9, 1, $noreg, 0, $noreg :: (load 8 from %ir.p0, addrspace 1)
%6:gr64, %7:gr64 = STATEPOINT 0, 0, 0, @foo, 2, 0, 2, 0, 2, 0, %8, %8(tied-def 0), killed %10, %0(tied-def 1), ...

It is synthetic (i.e. we do no generate such MIR from any IR), but still not invalid

• Mark MMOs for gc register spill slots as load/store ones;
• Add assert that there is only one EHPad;

I will incorporate this into D81647, since fix will be even simpler there.

This was landed as part of larger patch (D81648) for which this was a blocker. Abandoning this review.

In D81645#2159907, @thegameg wrote:

Hi, I see CodeGen/X86/statepoint-vreg.mir failing with UBSAN enabled on our internal bots:

That EHPad reload tracking does not fit very well in existing design. I added it as a separate entity stored in StatepointProcessor and passed to
StatepointState::insertReloads.
Ideally, I would insert all reloads in a single sweep after all statepoints has been processed. But I did not find a clean way to do that without refactoring
(like merging StatepointStates functionality into`StatepointProcessor`).

Add tracking of reloads inserted in landing pads.

Update to reflect current state of development

Another attempt

Remove accidently added test option

Add test demonstrating statepoint operand folding.

Rework slot reservation according to comments.
Add an option to disable copy propagation.

Clear DerivedPtrMap at new statepoint.

In D81648#2146051, @reames wrote:

Second, there appears to be a semantic problem around the handling of base vs derived slots unless we *always* spill the base. We can't tie both uses to a single def. This may warrant some offline discussion.

Another attempt to submit update.

Addressed comments.

Restore accidently destroyed review.

Changed DerivedPtrMap and moved it to StatepointLowering.h as it only
needed for local gc.relocate processing;
Rebased on tip, rewrote lowerStatepointMetaArgs as been told;
Deleted test mods, will add separate test later;