Thanks for the explanation. Summary of inline discussion so far:
NarrowScalar G_SEXT_INREG cannot have decent (able to combine away artifacts) mir test with this patch alone since there are problems with artifact combiner.
Approach 1: narrowScalar G_SEXT_INREG with G_UNMERGE/G_MERGE + D61787. Able to perform all combines introduced so far and generates desired output.
Approach 2: narrowScalar G_SEXT_INREG with G_TRUNC/G_SEXT + TODO: introduce more artifacts combines and fix artifact combiner to support them.
I expect that both approaches should have similar performance and generate equivalent output.
Are there there cases where Approach 2 generates better code, as I am now convinced that Approach 2 will have similar (if not better ?) performance compared to Approach 1?

LGTM.

Addressed review comments.

@volkan @aemerson @arsenm Here is brief explanation of changes in tests.

Most targets I know would select G_ZEXT_INREG to an AND using either an inline or materialized immediate at which point we haven't really gained anything by protecting it against harmful 'optimization'.

My only consideration was that is faster to narrow scalar G_ZEXT_INREG, then to narrow scalar G_AND and G_CONSTANT. On the other hand AND has simple narrow scalar unlike G_SHL and G_ASHR so it is not that big performance/code size improvement compared to G_SEXT_INREG. Also as sign and zero extend are most of the time mentioned together, I thought that we could add G_ZEXT_INREG alongside with G_SEXT_INREG.

Perfect. What about G_ZEXT_INREG since it is more efficient to narrow scalar G_ZEXT_INREG then bitwise instruction with some bit mask?

LGTM.

Both GNU assembler and LLVM show warning if odd floating-point register appears in an asm file. As far as I understand the -mno-odd-spreg prevents using odd registers by backend, but does not prevent inserting such registers into asm file directly by a user.

Thanks for clarification.

LGTM.

I don't see other reason for registers form OddSPRegClass to be declared as as Reserved other then to affect Allocation order in register allocation.
From description of nooddspreg : "Disable odd numbered single-precision registers". I would say that we only need to make sure that odd float registers can't be used during register allocation that is to affect Allocation order in some way to make sure odd registers don't appear there. I saw that similar problem for msa was handled with use of different register class (MSA128WRegClass or MSA128WEvensRegClass) in MipsSETargetLowering::emitCOPY_FW.
Here this is done with AltOrders without having to define registers from OddSPRegClass as Reserved. MipsGenRegisterInfo.inc also got smaller, everything looks good from my side.

LGTM.

I did not consider the case where sequence of instruction is legal, but individual instructions are not.
Condition when we throw an error might become
if (ArtifactList.empty() && TryLaterArtifactList.empty())
but other then that, there is no conflicts with artifact combining so it should not be a problem.

I agree that this is an important issue and that it should be implemented. I have already done some work in this direction and you can find a description of my work in the following text. Any comment is very welcome.

I added this patch to show how we can handle G_SMULH in narrowScalarMul, will add the test in the future.

Addressed review comments.

LGTM for the initial version of the patch.

microMIPS r6 handles float move with FMOV_S_MMR6 instruction mappings in .td file, with that in mind we should do the same with the double move instruction.
Despite the fact that change in /lib/Target/Mips/MipsSEInstrInfo.cpp results in the same output for this test, it should be addressed in another patch. Goal of that patch would be to properly select microMIPS move instruction based on register class used in copy instruction.

LGTM

I see. I think that in order to keep up with current implementation of microMIPS r6 in MicroMips32r6InstrInfo.td we should map microMIPS instruction to its corresponding standard encoding instruction when necessary.
According to documentation cb e5 has assembler format swsp $ra, 20($sp) but since here both clang and gcc use assembler format sw $ra, 20($sp) I think that we should keep the same behavior.
I would prefer solution in which when target instruction is selected it cannot be changed later. Alternatively for efficiency pseudo instruction could be selected and expanded into target instruction later. This approach would allow faster localization if problem occurs.
Regarding microMIPS r6 implementation I think that we should add both " patterns / manual instruction select" and "instruction mapping" when possible for completeness, since both are present. "Instruction mapping" approach also introduces some code duplication since often there is no difference between microMIPS pre-r6 and r6 instructions.
I agree that mapping in .td file is the best solution here.

Rebased

Rebased.

Addressed review comments.

SWSP instruction has the same encoding for both standard and r6 microMIPS (LOAD_STORE_SP_FM_MM16<0x32>).
If we change SWSP_MM from ISA_MICROMIPS32_NOT_MIPS32R6 to ISA_MICROMIPS, SWSP_MM could be used for R6 size reduction also.
SWSP_MMR6 looks redundant?

FMOV_D64_MM cannot be selected. Maybe you can do the following change instead in file
/lib/Target/Mips/MipsSEInstrInfo.cpp
line 147:

else if (Mips::FGR64RegClass.contains(DestReg, SrcReg))
  Opc = isMicroMips ? Mips::FMOV_D64_MM : Mips::FMOV_D64;

Addressed review comments.

selectImpl in some cases deletes I (using eraseFromParent()) and creates new instruction that is inserted in place of I in machine basic block.
In such cases I.getOpcode() accesses memory that was freed and can return unpredictable value.
For that reason we now select G_MUL manually before call to selectImpl.

Reverted in https://reviews.llvm.org/rL355219
since it causes failure on bot that tests clang built with address sanitizer.

We need to wait for NarrowScalar of G_SEXT and G_ZEXT and for perfecting artifact legalization
(since here it depends in which order we attempt to combine artifacts that are chained).

Restrict changes to MIPS backend only.
Use shouldFoldShiftPairToMask to avoid all attempts
to combine shifts if operands have vector type.