This PR adds basic FPU support for the MIPS R5900 processor used in the
PlayStation 2 Emotion Engine. The R5900 has a non-standard
single-precision-only FPU with limited functionality compared to
standard MIPS FPUs. Just like the previous r5900 PR, only existing
instructions are used to implement basic support first.
## Changes
### Infrastructure for single-precision-only FPU (ce13ddea7bc7)
- Add `isSingleFloat()` method to MipsAsmParser
- Add `SINGLE` FpABIKind to MipsABIFlagsSection
- Properly set CPR1Size and FpABI for single-float mode
- Exclude double-precision PseudoCVT instructions when using
single-float
### R5900 FPU support (13032c4d55b2)
- Switch R5900 from soft-float to single-float mode
- Implement R5900-specific FPU lowering with limited compare conditions
- Use CVT.W.S instead of TRUNC.W.S for FP-to-int conversion (R5900 lacks
TRUNC)
- Add test coverage for R5900 FPU instructions and comparisons
### Invalidate unsupported FPU instructions (ee4222711dab)
- Add predicates to exclude FPU instructions not supported by the R5900
- Add `C_COND_NOTR5900_M` multiclass for unsupported compare conditions
- Add `ISA_MIPS2_NOT_R5900` predicate for ROUND/TRUNC/CEIL/FLOOR.W.S
- Add test coverage for invalid R5900 FPU instructions
## R5900 FPU Limitations
The R5900 FPU differs from standard MIPS FPUs in several ways:
| Feature | Standard MIPS | R5900 |
|---------|---------------|-------|
| Precision | Single + Double | Single only |
| Compare conditions | 16 | 4 (C.F, C.EQ, C.LT, C.LE) |
| Rounding instructions | ROUND/TRUNC/CEIL/FLOOR.W.S | None (use
CVT.W.S) |
## Test Plan
- [x] Added `llvm/test/MC/Mips/r5900-fpu.s` - tests valid R5900 FPU
instructions
- [x] Added `llvm/test/MC/Mips/r5900-invalid.s` - tests rejection of
unsupported instructions
- [x] Added R5900 FPU comparison tests in
`llvm/test/CodeGen/Mips/fcmp.ll`
Some trailing kill/dead register operands may added by
MachineInstr::addRegisterKilled or MachineInstr::addRegisterDead, which
uses the overlap registers same with the operand 1-4.
Let's remove them here as only 5 operands are assert existing.
MIPS16 cannot handle constant pools created by CTTZ table lookup
expansion. This causes "Cannot select" errors when trying to select
MipsISD::Lo nodes for constant pool addresses.
Modify the table lookup conditions to check ConstantPool operation
status, and only set ConstantPool to Custom in non-MIPS16 mode in MIPS
backend.
This ensures MIPS16 uses the ISD::CTPOP instead of attempting
unsupported constant pool operations.
Fix#61055.
Fix bug where Fast ISel incorrectly set `IncomingArgSize` to `0` for
functions with no arguments, since `MIPS O32` uses _the reserved
argument area_ of 16 bytes even for the functions with no args at all.
This PR adds basic support for the MIPS R5900 CPU, the Emotion Engine
processor used in the PlayStation 2.
**LLVM changes:**
- Add r5900 CPU definition (with soft float support for now)
- Disable instructions not supported by r5900 (64-bit multiply/divide,
LL/SC atomics, COP3)
- Add r5900 specific short loop delay slot fix (hardware errata
workaround)
- Set ISA extension `AFL_EXT_5900` in ELF flags for proper ABI
identification
**Clang changes:**
- Add r5900 as a valid CPU target for `-mcpu=r5900`
- Add r5900 to CPU test coverage
This is a followup to https://github.com/llvm/llvm-project/pull/171288,
which removed lowering of libcalls to SDAG nodes for most libcalls that
get unconditionally canonicalized to intrinsics. This handles the
remaining fabs case, which I originally skipped due to larger test
impact.
These are long overdue for removal. These were originally a hack
to support loading half values before there was any / decent support
for the half type through the backend. There's no reason to continue
supporting these, they're equivalent to fpext/fptrunc with a bitcast.
SelectionDAG stopped translating these directly, and used the
bitcast + fp cast since f7a02c17628e825, so there's been no reason
to use these since 2014.
On platforms that soft promote `half`, using `lrint` intrinsics crashes
with the following:
SoftPromoteHalfOperand Op #0: t5: i32 = lrint t4
LLVM ERROR: Do not know how to soft promote this operator's operand!
PLEASE submit a bug report to
https://github.com/llvm/llvm-project/issues/ and include the crash
backtrace.
Stack dump:
0. Program arguments:
/Users/tmgross/Documents/projects/llvm/llvm-build/bin/llc
-mtriple=riscv32
1. Running pass 'Function Pass Manager' on module '<stdin>'.
2. Running pass 'RISC-V DAG->DAG Pattern Instruction Selection' on
function '@test_lrint_ixx_f16'
Resolve this by adding a soft promotion. GISel is included since tests
cover both.
Fixes crash tests added in
https://github.com/llvm/llvm-project/pull/152662 for targets that use
`softPromoteHalfType`.
Co-authored-by: Folkert de Vries <folkert@folkertdev.nl>
If we compile a C code or IR file directly, the delay slot of BNE emit
by us won't be filled with a NOP.
We should fill it ourself, otherwise, the break instruction may be used
as the delay slot.
Some of the MIR test hit a bug where it errors if there is a
raw global reference as the referenced value. Worked around some
of those by just keeping a no-op bitcast constant expression.
FIX: #172459
Since SETCC returns i1 in IR level, and SEL_D needs f64, currently, we
expand FSELECT to:
MTC1_D64
SEL
which may generate needless mfc1 and mtc1.
In this patch, we add FGR64CC Register type, and support F32 to F64 in
MipsSEInstrInfo::copyPhysReg.
With the current custom match rules, we may generate code like
```
cmp.ueq.s $f0, $f12, $f14
mfc1 $1, $f0
not $1, $1
mtc1 $1, $f0
sel.s $f0, $f14, $f12
jrc $ra
```
With Expand, we can get:
```
cmp.ueq.s $f0, $f12, $f14
sel.s $f0, $f12, $f14
jrc $ra
```
Fixes: #172965
In fact MipsAsmParser::expandDivRem is in a so bad status:
1. Div may not execute at all in most case
```
.set reorder
bnez $3, $tmp0
div $zero, $2, $3
break 7
$tmp0:
```
`.set reorder` may insert a nop after bnez, which will skip `div` if $3
is not zero.
2. `break 6` is wrong here.
Because previous pr:
https://github.com/llvm/llvm-project/pull/136821 has test failures on
builder llvm-clang-x86_64-expensive-checks-ubuntu when enable
`-verify-machineinstrs`. So revert that pr.
This new pr change:
1. add `-verify-machineinstrs` in RUN command.
2. wirte register before reading to avoid error `Bad machine code: Using
an undefined physical register`.
Fix#47656.
This is a followup to https://github.com/llvm/llvm-project/pull/171114,
removing the handling for most libcalls that are already canonicalized
to intrinsics in the middle-end. The only remaining one is fabs, which
has more test coverage than the others.
SDAG currently tries to lower certain libcalls to ISD opcodes. However,
many of these are already canonicalized from libcalls to intrinsic in
the middle-end (and often already emitted as intrinsics in the
front-end).
I believe that SDAG should not be doing anything for such libcalls. This
PR just drops a single libcall to get consensus on the direction, as
these changes need a non-trivial amount of test updates.
A lot of the remaining libcalls *should* probably also be canonicalized
to intrinsics in the middle-end when annotated with `memory(none)`, but
that would require additional work in SimplifyLibCalls.
Passing the context to `Inst.dump_pretty()` allows printing symbolic
register names instead of `<MCOperand Reg:1234>` in the output.
I plan to use this in a future RVY test cases where we have register
class with the same name in assembly syntax, but different underlying
register enum values. Printing the name of the enum value makes it
easier to test that we selected the correct register.
Reviewed By: lenary
Pull Request: https://github.com/llvm/llvm-project/pull/171252
1. On GPR32 platform, expandIS_FPCLASS may fail due to ISD::BITCAST
double to int64 may fail. Let's FP_ROUND double to float first.
Since we use it if MinMax is zero only, so the flushing won't
break anything.
2. Only one IS_FPCLASS is needed. MinMax will always be RHS if equal.
So we can select between LHS and MinMax.
It will even safe if FP_ROUND flush a small LHS, as if LHS is not zero
then, MinMax won't be Zero, so we will always use MinMax.
---------
Co-authored-by: Nikita Popov <github@npopov.com>
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
This consists of marking the various strict opcodes as legal, and
adjusting instruction selection patterns so that 'op' is 'any_op'. The
changes are similar to those in D114946 for AArch64 and #160696 for ARM.
Only Mips32/64 FPU instructions are affected.
Added lowering for for STRICT_FP_TO_UINT and STRICT_FP_TO_SINT ops.
This helps clean up some more legalization artefacts during
legalization, in a similar way to other operations, and helps some of
the DUP cases get through legalization successfully.
Previously if we had a subregister extract reading from a
full copy, the no-subregister incoming copy would overwrite
the DefSubReg index of the folding context.
There's one ugly rvv regression, but it's a downstream
issue of this; an unnecessary same class reg-to-reg full copy
was avoided.
This patch aims at making the combination of single-float and N32/N64
ABI properly work.
Right now when both options are enabled the compiler chooses an
incorrect ABI and in some cases even generates wrong instructions.
The floating point behavior on MIPS is controlled through 3 flags:
soft-float, single-float, fp64. This makes things complicated because
fp64 indicates the presence of 64bit floating point registers, but
cannot be easily disabled (the mips3 feature require it, but mips3 CPUs
with only 32bit floating point exist). Also if fp64 is missing it
doesn't actually disable 64bit floating point operations, because
certain MIPS1/2 CPUs support 64bit floating point with 32bit registers,
hence the single-float option.
I'm guessing that originally single-float was only intended for the
latter case, and that's the reason why it doesn't properly work on 64bit
targets.
So this patch does the following:
- Make single-float a "master disable", even if fp64 is enabled this
should completely disable generation of 64bit floating point operations,
making it available on targets which hard require fp64.
- Add proper calling conventions for N32/N64 single-float combinations.
- Fixup codegen to not generate certain 64bit floating point operations,
apparently not assigning a register class to f64 values is not enough to
prevent them from showing up.
- Add tests for the new calling conventions and codegen.
Modify instr movn/movz to mixture of beq, move, and sc.
Because atomic-min-max.ll test broken on the expensive builder, I revert
https://github.com/llvm/llvm-project/pull/149983 and resubmit this PR.
The broken reason:
In i16/i8 function expandAtomicBinOpSubword, we use two successor
after loop2MBB, one does not specify the second parameter, the other
use BranchProbability::getOne() that means 100% probability. This is
contradictory. And the second successor is also specified incorrectly.
The changess:
* llvm/lib/Target/Mips/MipsExpandPseudo.cpp:
Change loop2MBB`s second successor to correct one and delete the
second parameter BranchProbability::getOne().
* llvm/test/CodeGen/Mips/atomic-min-max.ll:
Add -verify-machineinstrs option in RUN command;
Modify i16 test and i8 test according to the changes.
Fix#145411.
The original version of this change inadvertently dropped
b6e19b35cd87f3167a0f04a61a12016b935ab1ea. This version retains that fix
as well as adding tests for it and an explanation for why it is needed.
Replace Mips custom logic for retaining information about original types
in calling convention lowering by directly querying the OrigTy that is
now available.
There is one change in behavior here: If the return type is a struct
containing fp128 plus additional members, the result is now different,
as we no longer special case to a single fp128 member. I believe this is
fine, because this is a fake ABI anyway: Such cases should actually use
sret, and as such are a frontend responsibility, and Clang will indeed
emit these as sret, not as a return value struct. So this only impacts
manually written IR tests.
Mips requires fp128 args/returns to be passed differently than i128. It
handles this by inspecting the pre-legalization type. However, for soft
float libcalls, the original type is currently not provided (it will
look like a i128 call). To work around that, MIPS maintains a list of
libcalls working on fp128.
This patch removes that list by providing the original, pre-softening
type to calling convention lowering. This is done by carrying additional
information in CallLoweringInfo, as we unfortunately do need both types
(we want the un-softened type for OrigTy, but we need the softened type
for the actual register assignment etc.)
This is in preparation for completely removing all the custom
pre-analysis code in the Mips backend and replacing it with use of
OrigTy.
In review of bbde6b, I had originally proposed that we support the
legacy text format. As review evolved, it bacame clear this had been a
bad idea (too much complexity), but in order to let that patch finally
move forward, I approved the change with the variant. This change undoes
the variant, and updates all the tests to just use the array form.
Many backends are missing either all tests for lrint, or specifically
those for f16, which currently crashes for `softPromoteHalf` targets.
For a number of popular backends, do the following:
* Ensure f16, f32, f64, and f128 are all covered
* Ensure both a 32- and 64-bit target are tested, if relevant
* Add `nounwind` to clean up CFI output
* Add a test covering the above if one did not exist
* Always specify the integer type in intrinsic calls
There are quite a few FIXMEs here, especially for `f16`, but much of
this will be resolved in the near future.
