[Mips] Set setMaxAtomicSizeInBitsSupported

[brad]

Summary

Set setMaxAtomicSizeInBitsSupported for Mips. Set the value as appropriate for 64-bit MIPS vs 32-bit and take MIPS-I into consideration.

I am not quite sure if I used the appropriate Subtarget checks.

[brad]

Use update_llc_test_checks.py to update test.

[brad]

ping.

[arsenm]

llvm/lib/Target/Mips/MipsISelLowering.cpp

500–501

Else case doesn't make sense to me but I know nothing about mips

[brad]

llvm/lib/Target/Mips/MipsISelLowering.cpp

500–501

Else case doesn't make sense to me but I know nothing about mips

To deal with MIPS-I not having support for atomics.

[brad]

ping.

[brad]

ping.

[wzssyqa]

llvm/lib/Target/Mips/MipsISelLowering.cpp

500–501

Sorry for me. I am no idea about what's the mean of the value of setMaxAtomicSizeInBitsSupported.

Maybe:

1. load/store instructions no quirky behavior: an instruction can be split to in result. If so, MIPS has never this problem since MIPS I.
2. normal load/store instructions can make sure that the data sync in a multicore system. If so, MIPS never archives this.
3. architecture has some instructions to help atomic ops. If so, MIPS has LL/SC since MIPS II.

[brad]

llvm/lib/Target/Mips/MipsISelLowering.cpp

500–501

setMaxAtomicSizeInBitsSupported() indicates the maximum size of supported atomic operations that are *all* lock-free. 32-bit MIPS does not have hardware support for lock-free 64-bit atomics.

[wzssyqa]

llvm/lib/Target/Mips/MipsISelLowering.cpp

500–501

Ohh, Yes, ldc1 is available since MIPS II.

and

ldc1 $f0, 0($4)
mfc1 $2, $f0
mfc1 $3, $f1

is wrong for MIPS32 FP64 ABI.
For MIPS32 FP64 ABI(support MIPS32R2+ only), it should be like:

ldc1 $f0, 0($4)
mfc1 $2, $f0
mfhc1 $3, $f0

[efriedma]

Makes sense to me.

For MIPS 1, we have essentially two choices: either we use setMaxAtomicSizeInBitsSupported(0), and generate __atomic_* calls, or we set setMaxAtomicSizeInBitsSupported(32), and generate native load/store with __sync_* calls for cmpxchg/atomicrmw. Either way, we can't actually provide implementations; the user has to make it work somehow. See D137980 for a similar discussion... but generating __sync_* calls seems to cause less trouble. (Not sure if anyone cares about MIPS 1 these days, though.)

[Tazdevil971]

Hi! Sorry to jump in randomly, but it just so happens that I was working on a very similar patch right now. Funnily enough I need to make everything work on MIPS I, because there are still people caring for that target, mainly in the homebrew scene as the CPU for the Playstation 1 and coprocessor of the Playstation 2 both are MIPS I targets.

Wouldn't it be more correct to set atomic widths to 0 and generate __atomic_* calls? As just emitting sync fences on CAS/RMW operations break with multithreading/preemption? I'm not so sure about the Playstation 1 but I'm pretty sure the Playstation 2 has multithreading support on the coprocessor. Also, as it has already been pointed out, MIPS I doesn't even support sync operations, so relying on some implementation of them, to me, seems more complicated to achieve.

[efriedma]

Wouldn't it be more correct to set atomic widths to 0 and generate __atomic_* calls?

You need some sort of operating-system level magic to make atomicrmw/cmpxchg work without ll/sc. Disabling interrupts, or a restartable sequence, or something along those lines. Most of the ways you'd implement that end up being compatible with lowering atomic load/store to plain load/store operations. Granted, other implementations are possible.

[Tazdevil971]

Yes exactly, what I'm saying is that if we just emit sync fences (in the form of libcalls) for CAS/RMW operations it might become impossible to target systems that have some sort of preemption. So I personally would prefer to set atomic width to 0 and generate libcalls for all atomic operations, so implementors for specific environments can do the right thing for the platform.

[efriedma]

Baremetal Playstation 1 is likely the only MIPS1 target anyone will ever use with LLVM, so we should do whatever makes sense there. I don't think it makes sense to theorycraft configurations that don't exist. (If MIPS1 Linux were a thing, it would probably do something like https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt .)

[Tazdevil971]

Fair enough. Looking more in detail at Playstation 1 and 2, they both use cooperative multithreading so preemption is not an issue. So for these targets it doesn't really make a difference.

[brad]

Just wanted to point out this recent github bug report..

https://github.com/llvm/llvm-project/issues/61166

[wzssyqa]

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

[wzssyqa]

In fact, here we have more than 1 problems:

1. clang --target=mips-gnu-linux -march=mips1 fails due to lack of sync https://github.com/llvm/llvm-project/issues/61166

2. float instructions are always emit even +softfloat option is given.

3. ./bin/llc -global-isel -mtriple=mips64el-linux-gnu -verify-machineinstrs ../llvm/test/CodeGen/Mips/GlobalISel/llvm-ir/load_atomic.ll -o - always fails.

[wzssyqa]

To work with MIPS1, I guess

if (!Subtarget.hasMips2())
  setMaxAtomicSizeInBitsSupported(0);

Should be enough.

[efriedma]

LGTM. (I was sort of hoping for someone with Mips expertise to show up to approve this, but lacking that, I don't see any issues here.)

[wzssyqa]

This comment was removed by wzssyqa.

[wzssyqa]

This comment was removed by wzssyqa.

[wzssyqa]

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.

So, I agree with Brad's patch now.

Maybe, in future we can determine which core won't split it.

llvm/lib/Target/Mips/MipsISelLowering.cpp

if (ABI.IsO32()) {
     setLibcallName(RTLIB::SHL_I128, nullptr);
     setLibcallName(RTLIB::SRL_I128, nullptr);
     setLibcallName(RTLIB::SRA_I128, nullptr);
     setLibcallName(RTLIB::MUL_I128, nullptr);
     setLibcallName(RTLIB::MULO_I64, nullptr);
     setLibcallName(RTLIB::MULO_I128, nullptr);
   }
 
+  if (Subtarget.isGP64bit())
+    setMaxAtomicSizeInBitsSupported(64);
+  else if (Subtarget.hasMips2())
+    setMaxAtomicSizeInBitsSupported(32);
+  else
+    setMaxAtomicSizeInBitsSupported(0);
+
   setMinFunctionAlignment(Subtarget.isGP64bit() ? Align(8) : Align(4));
 
   // The arguments on the stack are defined in terms of 4-byte slots on O32
   // and 8-byte slots on N32/N64.
   setMinStackArgumentAlignment((ABI.IsN32() || ABI.IsN64()) ? Align(8)
                                                             : Align(4));
 
   setStackPointerRegisterToSaveRestore(ABI.IsN64() ? Mips::SP_64 : Mips::SP);