LGTM

LGTM

LGTM

LGTM

If not a new LegalizeAction maybe some other way ( like one more argument ) for targets to chose whether to create G_EXTRACT or CONCAT_VECTORS + G_UNMERGE_VALUES ?
I am not that familiar with the problem we are dealing here, but shouldn't insert + extract that are created during moreElements combine away like anyext + trunc for widen scalar ?
So this would be extract + insert into implicit def -> copy extract source if it had same type like implicit def (this is 3 instruction combine). Might that fix some of the problems?

This looks like a good candidate for new LegalizeAction ( MoreElementsLCM or something more appropriate ) that could be preferable more elements option for targets that support G_CONCAT_VECTORS and G_UNMERGE_VALUES for large vector sizes (large enough to hold LCM(WideTy, OrigTy) ).
Current algorithm seems to be designed for targets that prefer not to deal with vector types larger then WideTy. It would be difficult for them to deal with G_CONCAT_VECTORS and G_UNMERGE_VALUES that are not legal and likely hard to combine since they have different small LLTs.

Add comment in narrow scalar for cttz.

Add comment, leave assert for another patch.

Add check that OrigType is scalar and NarrowTy == OrigType/2. Fix build unmerge.

Add check that OrigType is scalar and NarrowTy == OrigType/2. Fix build unmerge.

Add check that OrigType is scalar and NarrowTy == OrigType/2. Fix build unmerge.

Ping.

Rebase and update.

LGTM.

G_CONSTANT can already directly have a pointer type, so I don't see a reason that the extra G_INTTOPTR needs to be involved.

When I started this patch I thought the same. nullptr was translated like that some time ago, D44762 changed it to what we have now. NullPtrValue was meant to match IRTranslator's translation of llvm-ir null

Buildbot failures depend on compiler used to build clang.
Problem was in order which new MachineInstructions get inserted into MachineFunction.
Generated assembler does the same thing, but regression tests require consistent behavior regardless of compiler used.
In:

return B.buildOr(Dst, B.buildLShr(Ty, B.buildAnd(Ty, Src, MaskLoNTo0), C_N),
                 B.buildAnd(Ty, B.buildShl(Ty, Src, C_N), MaskLoNTo0));

it is important which method was executed first since they insert MachineInstructions into MachineFunction. Order of execution:
gcc

B.buildAnd(Ty, B.buildShl(Ty, Src, C_N), MaskLoNTo0)
B.buildLShr(Ty, B.buildAnd(Ty, Src, MaskLoNTo0), C_N)

Ping.

This patch needs only bswap, I just checked and it worked fine for me, what was the error?

Forgot to run regression tests for amd.

Rebase and ping.

Attempt to switch to insertelt and extractelt for mips. Simplified a few lines.

LGTM.

LGTM.

With removed xfail from tests, this looks good to me. I would like to hear if other reviewers have comments.

RegbankSelect doesn't track newly created instruction and I had to set reg bank manually. Here is the patch that sets regbank for newly created COPY instructions

Since n32 worked before, you could change

It accepts la pseudo instruction on 64-bit arch and just shows a warning.

It accepts la pseudo instruction on arch with 64-bit pointers and just shows a warning.

I don't fully understand G_BUILD_VECTOR_TRUNC. Such opcode does not exist in llvm-ir and as such can only be created in legalizer or later (at the moment at least). The problem here is the context sensitive legality (we still avoid this) along side with type legality. e.g. types might be fine but we still can't select an instructions because vector is built from different virtual registers (so splat is not an option) and we should perform lower. At the current state of legalizer I don't think it is possible to have it legal for type and as such I planned to handle it with custom legalization by either context sensitive select or lower.

Ping.

LGTM.

LGTM.

Correction from previous comment, tests for SaaAddr and SaadAddr are already present.

Missing test for SaaAddr and SaadAddr.

I have just saw these two asserts that forbid different types of vector scalar and element scalar
https://github.com/llvm/llvm-project/blob/a0324e911374441151903ed0d828e0fc1994c167/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp#L1090
https://github.com/llvm/llvm-project/blob/a0324e911374441151903ed0d828e0fc1994c167/llvm/lib/CodeGen/GlobalISel/MachineIRBuilder.cpp#L1100
Widen scalar change does not trigger asserts since it only changes operand instead of making new instruction. How do we approach this issue then?
Btw, based on G_ZEXTLOAD and G_SEXTLOAD, are G_SEXT_EXTRACT_VECTOR_ELT and G_ZEXT_EXTRACT_VECTOR_ELT a consideration?
They would have different element scalar then vector scalar.

I don't understand the motivation.
The vector element and insert element type need to match, but it appears there's a missing verifier check

This is definitely true for llvm-ir insertelement and extractvalue.
But SDAG nodes ISD::INSERT_VECTOR_ELT and ISD::EXTRACT_VECTOR_ELT don't follow this,
Mips uses DAGTypeLegalizer::PromoteIntegerResult for i8 and i16 and promotes them to i32 leaving vector scalar type unchanged.
In .td file element being inserted/extracted has i32 operand type (for i8, i16 and i32) and instruction is selected based on vector type (v16i8, v8i16, v4i32).

D69513 goes first, following what SDAG does
%8:_(<16 x s8>) = G_INSERT_VECTOR_ELT %6:_, %7:_(s8), %5:_(s32)
should change only insert elt scalar type, and leave vector scalar type as is
%8:_(<16 x s8>) = G_INSERT_VECTOR_ELT %6:_, %7:_(s32), %5:_(s32) (in function: insert_i8)
insert instruction is selected based on vector type, inserted scalar is always i32 (i32 or i64 for mips64)

Address review comments.

Fix names of test files, be more specific in summary about llvm.fabs.* type since MIPS can generate scalar llvm.fabs.* but cannot generate vector llvm.fabs.*.