Thanks for the quick review @arsenm!

LGTM.

• Replace some unsigned into Register

This was just a patch to illustrate a possible direction.

• Remove asserts already covered by the verifier
• Put .getType calls into a variable.

• Replace check with an assertion
• Update comments with pre-conditions

• Use ArrayRef instead of const SmallVectorImpl&
• Add tests with pointer types.

LGTM

Hi Matt,

LGTM

LGTM

The swifterror test change in this patch is one example. Live ranges over function calls can be problematic if under register pressure, which can cause additional moves, if not spills. There are others of course

Hi Amara,

I don't think this patch is correct in the sense that having statepoints depend on GreedyRegAlloc is a non-starter.
Indeed, that means that now any configuration that doesn't use greedy reg alloc (like fast or basic reg alloc) will generate incorrect code with respect to state point spilling.

Suggestion of a small refactoring below.

Hi Jinsong,

LGTM with a test case.

LGTM for the generic part.

It was added by D46315

Remove loop entirely. Ultimately determineCalleeSaves adds everything from MCRegAliasIterator anyway

Let's go with that for now with one caveat. Does the code build without ANDGPU?
I.e., does the callingconv enum get generated?

General direction LGTM but there's a bug in the current patch unless I am mistaken.

I second Daniel's comment, this is RegBankSelect's job to do this choice and the Legalizer shouldn't need to know about f64 vs. s64.

Maybe adding an MCRegister that's nearly identical might be a future improvement? That way it could enforce MCRegister->Register is OK, but Register->MCRegister is not

Thanks for doing this Matt, this is a long due clean-up.
I haven't looked carefully at all the changes, but the general direction LGTM.

Those rules work when there's a load/store for every type but they run into unable-to-legalize if that's not the case.

LGTM modulo want @paquette pointed out.

Nitpicks below.

Nitpicks below.

Agree, the fix is more important than the performance loss at this point.

Hi Jonas,

Hi Amara,

LGTM.

Looks reasonable!

What is the use case for this?

LGTM.
Nitpicks on the test below.

Hi Daniel,

Please provide us with more details about your idea.

LGTM

did anything like this come up in the past?

LGTM

Looks good to me, modulo the order in which we check the hints.

@Quentin: This has the same common-code change as in D58923, with the added VRM to foldMemoryOperand(). You seemed fine with this change, right?

LGTM. Nitpicks below.