[all-commits] [llvm/llvm-project] 2edcde: [MIPS] Add -mfix4300 flag to enable vr4300 mulmul ...

[Simon Atanasyan via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2edcde00cb396cc17d8d8b171a6ebaa97fd30e59
      https://github.com/llvm/llvm-project/commit/2edcde00cb396cc17d8d8b171a6ebaa97fd30e59
  Author: Random <ikhbeilfnpz.enfmjk at gmail.com>
  Date:   2021-12-31 (Fri, 31 Dec 2021)

  Changed paths:
    M clang/include/clang/Driver/Options.td
    M clang/lib/Driver/ToolChains/Clang.cpp
    M llvm/lib/Target/Mips/CMakeLists.txt
    M llvm/lib/Target/Mips/Mips.h
    A llvm/lib/Target/Mips/MipsMulMulBugPass.cpp
    M llvm/lib/Target/Mips/MipsTargetMachine.cpp
    A llvm/test/CodeGen/Mips/vr4300-mulbranch.ll
    A llvm/test/CodeGen/Mips/vr4300-mulmul.ll

  Log Message:
  -----------
  [MIPS] Add -mfix4300 flag to enable vr4300 mulmul bugfix pass

Early revisions of the VR4300 have a hardware bug where two consecutive
multiplications can produce an incorrect result in the second multiply.
This revision adds the `-mfix4300` flag to llvm (and clang) which, when
passed, provides a software fix for this issue.

More precise description of the "mulmul" bug:
```
mul.[s,d] fd,fs,ft
mul.[s,d] fd,fs,ft  or  [D]MULT[U] rs,rt
```

When the above sequence is executed by the CPU, if at least one of the
source operands of the first mul instruction happens to be `sNaN`, `0`
or `Infinity`, then the second mul instruction may produce an incorrect
result. This can happen both if the two mul instructions are next to each
other and if the first one is in a delay slot and the second is the first
instruction of the branch target.

Description of the fix:
This fix adds a backend pass to llvm which scans for mul instructions in
each basic block and inserts a nop whenever the following conditions are
met:

 - The current instruction is a single or double-precision floating-point
   mul instruction.
 - The next instruction is either a mul instruction (any kind) or a branch
   instruction.

Differential Revision: https://reviews.llvm.org/D116238