Understood, glad to see it finally resolved.

LGTM

In that case I'll commit this patch, the issue with float routine names being kept in the MIPS backend can be deferred to a separate patch since it does not pertain to fmaxl only.

My only goal was to correct the return value of fmaxl to be interpreted as a 128bit float.
As it stands the return value is being interpreted as an i128 and fetched from the wrong registers.

LGTM

LGTM

LGTM

It seems that I cannot apply this patch without applying D51482 first, because that patch introduces the test file.
They should be either decoupled or made dependent on phabricator to indicate the relation.

LGTM

LGTM

Expanded a piece of code using switch cases as suggested.

Update test file to cover all of the patterns included in the change.

Added test cases.

@joerg Would it be okay to commit this?
The LIBUNWIND_HAS_GCC_S_LIB although declared, did not have its value used anywhere unlike LIBUNWIND_HAS_C_LIB and LIBUNWIND_HAS_DL_LIB which had been declared/used similarly.
The added line is only executed if the following block is (cmake/config-ix.cmake):

if (NOT LIBUNWIND_USE_COMPILER_RT)
  check_library_exists(gcc_s __gcc_personality_v0 "" LIBUNWIND_HAS_GCC_S_LIB)
endif()

in which case compiler-rt is not being used anyway, if that's what you were referring to.

Add test file.

Not anymore, I'd like to have it reviewed.
I rolled it back to the version similar to the one you reviewed initially.

Revert patch back to the previous version.

Looks good, no failures this time.

Added target hooks to replace the sign_extend with the sign_extend_inreg node which will get pattern matched with the SLL64_64 thus providing the needed sign extension.
The second target hook is introduced to keep the sign_extend_inreg node from being combined away.

Forgot to mark this explicitly as still being WIP, since we are missing sign extensions at some places.

LGTM.

There appear to be a couple of test failures for this patch, at least on my end.
I am at r335143.

Looks okay, one small remark

@sdardis I hadn't checked myself before posting but as you say that is indeed what clang-format outputs.

In that case LGTM.

Looks okay, you could add a test case if you feel the change requires it.

Looks okay, you could add a test case if you feel the change requires it.

LGTM.

LGTM.

Mostly comment fix suggestions

LGTM.

Looks okay except it seems that other changes have snuck in.
From what I can tell the patch was created before rL333288 got committed.
In addition this patch appears to contain changes from D47075 as well.
Please rebase.

LGTM

LGTM

LGTM

This looks fine, regarding the instructions introduced instead of their matching itinerary classes.

LGTM

In D35985#832657, @MatzeB wrote:

I would expect the live ranges of register units that are reserved to be empty and therefore naturally pass verification. Do you know why you end up having non-empty information in those live ranges? We should identify the cause for that and fix it.