Rebased and updated the patch. Now it seems like the past issues are gone.

Agreed on this solution D52878.

Updated the patch, so that the extra flags are added only when -static option is used.
Used @atanasyan 's solution for CMakeLists.txt from D56836#1362293.
Made equivalent for the Makefile.

@atanasyan That looks good. I tried to make an equivalent for the Makefile

--- SingleSource/UnitTests/C++11/Makefile	(revision 351547)
+++ SingleSource/UnitTests/C++11/Makefile	(working copy)
@@ -4,6 +4,11 @@

I am not sure if -static option passed as --cflag to lnt runtest enters the LDFLAGS. I guess it doesn't.
But if there is a way to check which options are passed as --cflags, we might be able to add -Wl, -whole-archive -lpthread -Wl -no-whole-archive only in case when static is used.
That would be my preferable option in this situation, but I couldn't find any clues on how to do that.

I agree with Simons comment that it's not MIPS specific issue, but in that case I think it would be nice to get comments from other maintainers for other targets.
I didn't see Simons comment and created something similar here D56836, but with some additional checks.

Comments resolved.

Patch committed.
https://reviews.llvm.org/rL350733
Closing manually because of typo in the commit message.

Update patch for context.

From what I found in rL336328, I believe that the idea was to mark registers as implicit-def which would prevent such an error.
One of the comments say:

Added necessary flags for Mips only.

Resolved some comments.

Updated patch to show full context.

Removed class forward declaration from MCExpr.cpp. It is not needed.

Comments addressed.
Test fixed. I have one other patch in progress which affects this test, and forgot to remove it before the submission.

LGTM

LGTM

Removed unnecessary changes.
Description updated.

Fix predicates and update tests.

Removed instruction definitions for FP32, which would, by the statement in the instruction manual, cause an unpredictable results.

After reviewing the instruction manual again, I noticed the following in the Restrictions section:
The result of this instruction is UNPREDICTABLE if the processor is executing in the FR=0 32-bit FPU register model; it is predictable if executing on a 64-bit FPU in the FR=1 mode, but not with FR=0, and not on a 32-bit FPU.
Which makes some of the definitions in the patch wrong. Should fix that.

Fix forgotten TODOs.

Comments addressed.

Comments addressed.

No need for this, now when D43283 is closed.

I guess there is no need to keep this alive any longer.

LGTM

Comments addressed.

LGTM

LGTM

Comments addressed.

Comments addressed.

Comment addressed.

Comments addressed.

Updated the patch, so that buildbots do not fail.
The problem was in forcing the extension to long branches in every iteration,
which causes infinite loop.