[PATCH] D122427: [MIPS] Initial support for MIPS-I load delay slots

[Spencer Alves via Phabricator via llvm-commits]

impiaaa added a comment.

> I'll try to find if there are any other differences between MIPS-I and MIPS-II.

Ok, I did some research. Here are the differences that I can find between MIPS-I and MIPS-II:

1. Delayed loads: Done.
2. "Branch likely" instructions: As far as I can tell, these are currently never emitted.
3. Atomic update: These instructions also do not appear to be emitted.
4. `sync`: As @ayrtonm discovered, this instruction can be emitted from atomic loads and stores. It is lowered from the `FENCE` higher-level instruction. I have a patch ready that expands it to a libcall instead on MIPS-I.
5. 64-bit coprocessor transfers: Emitted in `MipsFastISel::emitLoad`, `MipsFastISel::emitStore`, `MipsInstructionSelector::selectLoadStoreOpCode`, `MipsSEInstrInfo::loadRegFromStack`, and `MipsSEInstrInfo::storeRegToStack`. They can currently be expanded to two single-word transfers with `-mno-ldc1-sdc1`. This option should be set automatically when MIPS-I is selected, or rather a `hasMips2` check should be added everywhere that `NoDPLoadStore` is also checked.
6. Trap-on-condition: Emitted in `MipsFastISel::selectDivRem`, and MipsISelLowering.cpp `insertDivByZeroTrap` for checking for dividing by zero. The checks could be expanded to separate branch and `break` instructions. They can also currently be disabled entirely with `-mno-check-zero-division`.
7. Native directed rounding of floating-point to fixed-point: `trunc_w` is emitted in `MipsFastISel::selectFPToInt`, and `MipsInstructionSelector::select`. `MipsAsmParser::expandTrunc` already has code to expand the `trunc_w` pseudoinstruction, but I don't know if it's used by the assembler.
8. Floating-point square root: Emitted when `-ffast-math` is on. I haven't figured out yet where the code makes the decision how to lower the square-root intrinsic—there are other targets that do not have a native square-root instruction that properly expand it to a libcall.

> There is some documentation in llvm/doc/TestingGuide.rst, but there's no option to common up the checks. This test case does look small enough that it should be ok.

Now I see that most of the tests in this directory only test the positive case, not both the positive and negative cases like I did. For future tests I'll do that instead.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122427/new/

https://reviews.llvm.org/D122427