In D157896#4630236, @theraven wrote:

Looks fine to me, though I’ve never seen code using this macro. For a single (not yet implemented) consumer I’m not certain it’s worth putting in the compiler since the same place in the build system that adds the flag directing code generation can also add a -D flag.

In D158589#4612830, @jrtc27 wrote:

With the exception of 5, these all sound like garbage inline asm input? If you have a dangling delay slot at the end of the inline assembly, that's your problem, not the compiler's. And don't we default to reorder, anyway, so the only way to write that is to first .set noreorder?

In D158509#4611696, @MaskRay wrote:

Thank you for the patch. I think it would actually be nice that we probe the m32 multilib of x86_64-unknown-linux-gnu multilib first for --target=x86_64-unknown-linux-gnu -m32.

Unfortunately, due to various setArch code in computeTargetTriple (e.g. D54214), this change may change what lib they use.

In D158491#4607577, @MaskRay wrote:

This large pile of mips code makes me nervous. What I really want is to eliminate code related to some older mips ports.
For example, just claim that defined(__mips__) && __mips_isa_rev < 6 is not supported for sanitizers.

If https://reviews.llvm.org/D158509 is OK, this patch won't be needed.
In fact, we can remove MIPS*LTriples[], I guess.

I think that this is a step forward to drop *MIPSELTriples[].

This patch depends on https://reviews.llvm.org/D158491.

@MaskRay ping

In D157896#4594431, @MaskRay wrote:

In GCC, -mno-odd-spreg -modd-spreg affects code generation. If we don't implement the behavior, I am not sure we can define _MIPS_SPFPSET.

Actually, do we really want to define the macro? CodeSearch context:global _MIPS_SPFPSET -f:gcc|sysdeps/ (regex) gives no result.

In D156283#4595487, @compnerd wrote:

I think that @wzssyqa's analysis is correct - the extra space is fine to keep in the buffer.

@anton-afanasyev in clang/test/Driver/riscv64-toolchain.c,
the separator of path, some use just /, and some others use {{/|\\\\}}.
Do you know about why?

Errr, the risc-v test case is wrong...

I have no idea. As the the whole system, including the file name of gcc/binutils commands, is using the non-vendor triples.
Anyway, add a symlink won't be a very difficult problem. I can request it.

Thanks.

In D158183#4596086, @MaskRay wrote:

This change adds more code for Debian and its derivatives. I think this patch should justify itself by removing some complexity, e.g. removing some elements from *Triple* arrays.

*Triples* arrays are used much more than it designed to.

If this helps removing elements from *Triples* arrays, I will be in favor.

AArch64Triples[] should not contain aarch64-linux-gnu. Unfortunately, Debian patches GCC so that their GCC packages are installed to lib/gcc{,-cross}/aarch64-linux-gnu instead of lib/gcc{,-cross}/aarch64-{pc,unknown}-linux-gnu, so AArch64Triples[] has to contain aarch64-linux-gnu to support LLVM_DEFAULT_TARGET_TRIPLE (always normalized with "vendor") aarch64-unknown-linux-gnu.

In D158100#4594452, @MaskRay wrote:

See the commend I added in a07727199db0525e9d2df41e466a2a1611b3c8e1. " Please don't add more elements to *Triples".

These variables are workarounds so that, for example, --target=aarch64-unknown-linux-gnu can detect a aarch64-linux-gnu GCC installation (Debian target triples omit "vendor").

Yes. microMIPS support needs lots of work.

Swap MIPSTriples_legacy and MIPSTriples_r6.

In D156283#4590543, @MaskRay wrote:

In D156283#4590529, @wzssyqa wrote:

In D156283#4589972, @MaskRay wrote:

wzssyqa removed a reviewer: libunwind.

Some projects like libc++/libc++abi/libunwind add a default reviewer group. This ensures #libunwind people know changes going into libunwind. They may not comment, but they can do so when a change increasing maintenance burden catches their eye.

I added libunwind group back.
It was "blocking libunwind" previous. I have no idea what it means?

Someone in the #libunwind needs to click Accept as libunwind to make the differential green, otherwise it is in the Needs Review state even if there is an approval.

In D157900#4585658, @jrtc27 wrote:

Please include context; see https://llvm.org/docs/Phabricator.html#phabricator-request-review-web

I cannot reproduce it now ...
Abandon it.
When I can reproduce it, I will reopen it.

In D156283#4589972, @MaskRay wrote:

wzssyqa removed a reviewer: libunwind.

Some projects like libc++/libc++abi/libunwind add a default reviewer group. This ensures #libunwind people know changes going into libunwind. They may not comment, but they can do so when a change increasing maintenance burden catches their eye.

The downstream distribution can disable it by patch.

In D156283#4533871, @jrtc27 wrote:

Should space for them still exist in Registers_mips_o32/newabi, UNW_MIPS_HI/LO still be defined and the various things in __libunwind_config.h still account for them?

In D156283#4533871, @jrtc27 wrote:

Should space for them still exist in Registers_mips_o32/newabi, UNW_MIPS_HI/LO still be defined and the various things in __libunwind_config.h still account for them?

In D154589#4529394, @MaskRay wrote:

In D154589#4526560, @wzssyqa wrote:

How can I close this differential?

By closing, do you mean abandoning? I hope that @brad and @jrtc27 can make a suggestion.

How can I close this differential?

Thank you for your patch.

Sorry. It is my fault. With some dig, I know that some microarchitectures may split one ldc1/sdc1 to 2 micro-ops.
Thus we cannot be sure that it is atomic.

It is from the version of brad: https://reviews.llvm.org/D141189

To work with MIPS1, I guess

In fact, here we have more than 1 problems:

In fact, I don't think that it is a good idea to support MIPS I with degrading the performance of MIPS2+.

I agree with this patch, while I have no approval permission.

I noticed there are some lines like:

In D146269#4347514, @MaskRay wrote:

Is this the new GCC behavior?

ping...

@MaskRay ping?

@MaskRay can you help to submit this patch?

ping...

ping

In D146269#4201150, @jrtc27 wrote:

Tests?