LGTM.
Please wait couple days in case @RKSimon has some more comments/concerns

This change is caused https://github.com/llvm/llvm-project/issues/62286
Or simply exhibited existing problem in BUILD_VECTOR lowering on X86

Would be nice to have few dedicated tests. All existing test changes are noisy

LGTM.
I'll wait for a few days before landing it to let other reviewers speak up.

LGTM after assertion fix.
I'll take care of landing

Please make a separate NFC review with GCStrategy changes. Besides being common llvm review practice it will allow downstream projects to handle this API change without breakage.
With separate reviews/commit we will have time to update our downstream strategies before RS4GC starts using new API.
If they come in single commit, it will immediately break all existing RS4GC users.

@znix : I suggest you to remove GCStrategy cache from this patch (and use llvm::getGCStrategy() instead where necessary). I think it will unblock review.
We can figure out caching later/separately.

In D141110#4048764, @znix wrote:

I'll work on making a GCStrategyAnalysisPass then. Given RS4GC supports both the new and legacy pass manager, I assume this new pass needs to support both, too?

I think yes. Even though Legacy PM is deprecated, supporting it is just several extra lines.

Added couple folks who should be interested in this stuff :-)

BTW, there is no need to create new revision to reflect trunk changes. You could simply rebase your local branch and then update diffs for the existing review. This works well and is common practice.

OK, go ahead.

LGTM, but clean test up before committing.

Tried your patch together with my old uncommitted change which utilizes GCStrategy in IR Verifier and it works fine now. So LGTM.
Please wait few days for other reviewers to have a chance to comment.

Address review comments (fix typos).

In D140458#4010049, @znix wrote:

I'm not sure why the tests are failing? It looks like a linkage issue:

LLVM ERROR: unsupported GC: statepoint-example (did you remember to link and initialize the library?)

I'm not sure why this would occur in the tests, but not locally. I built with BUILD_SHARED_LIBS which I'm guessing has something to do with it, but llvm/lib/IR/BuiltinGCs.cpp (where the statepoint-example GC registration is located) is in LLVMCore so I'd expect it to always be initialised?

Address review comments.
Also include changes for pre-committed tests

I like it more that original fix, but I don't feel qualified to review :-)
Would be great if @qcolombet can have a look..

Rebase on tip after D138910 has been landed.

Get rid of temporary ChainToBase vector as suggested in review.

In D138910#3987383, @skatkov wrote:

BTW, now with you change, do we really need to copy Record.ChainToBase to ChainToBase?

Rebase on tip

LGTM.
(We perhaps should have removed RegA completely from MRI, LiveVariables etc, but I did not find interface for this. Are Registers append-only?)

I did a quick testing downstream (on X86) and did not encounter any issues. Looks good to me.

Rebase on top of relanded test.
Added TODO about recomputation of live range/liveness instead of bailing out.

Rebase on top of precommitted test

In general looks OK to me (modulo few style nits).
But I'm not an ISEL type legalization expert. Would be nice to have LGTM from someone else as well.

Idea is being able to push something like these though upstream:
https://reviews.llvm.org/D125690
https://reviews.llvm.org/D127892
From our downstream point of view they look reasonable, but we've encountered upstream resistance on first (so most likely will see it on second as well if we do it unconditionally)

Fix spaces in test to minimize differences

Rebase on top of precommitted test

ping

ping

Looks like this has to live downstream. Still I think if upstream provides some public api (CallBase::getParamElementType) it should be available to all users

In D125680#3522346, @vext01 wrote:

Please do not touch statepoint in this patch. If you do not really need it, leave it alone at all.

Just to clarify why I've proposed this:

llvm.experimental.stackmap, llvm.experimental.patchpoint and llvm.experimental.gc.statepoint used to all share the same DAG building code via a function called addStackMapLiveVars() in SelectionDAGBuilder.cpp.

No, Statepoint does not use this function.

In D125680#3522332, @vext01 wrote:

• make llvm.experimental.patchpoint and llvm.experimental.gc.statepoint legalise properly too.

In D125690#3516881, @nikic wrote:

Use of elementtype is discouraged -- it should only be used if there is no other solution. I don't want to add APIs legitimizing its use in this context without justification. For example, consider the llvm.memcpy.element.unordered.atomic intrinsics which specify an element size as an additional argument, rather than a precise element type.

In D125690#3516808, @nikic wrote:

We generally do not add in-tree methods if they have no in-tree users. I'm also rather skeptical about what you're trying to do here -- this would need some more detailed explanation of the use case.

Intrinsics allow to specify element type of its pointer arguments via elementtype attribute.
Atomic memory intrinsics hide this possibility behind quite complicated hierarchy. This patch makes it accessible for any interested party. I don't see what's wrong with that?

@MatzeB Matthias, is test statepoint-vreg-twoaddr.mir looks meaningful? If yes, I can precommit it to make changes more obvious. Also, any suggestion on improving description?
(Yes, I know that IR part in .mir test is redundant, but I find it handy when I occasionally have to modify tests)

Added test to show changes in TwoAddress pass.