[PATCH] D63938: [ARM] Stop using scalar FP instructions in integer-only MVE mode.

[Simon Tatham via Phabricator via llvm-commits]

simon_tatham created this revision.
simon_tatham added reviewers: dmgreen, ostannard.
Herald added subscribers: llvm-commits, hiraditya, kristof.beyls, javed.absar.
Herald added a project: LLVM.

If you compile with `-mattr=+mve` (enabling integer MVE instructions
but not floating-point ones), then the scalar FP //registers// exist
and it's legal to move things in and out of them, load and store them,
but it's not legal to do arithmetic on them.

In D60708 <https://reviews.llvm.org/D60708>, the calls to `addRegisterClass` in ARMISelLowering that
enable use of the scalar FP registers became conditionalised on
`Subtarget->hasFPRegs()` instead of `Subtarget->hasVFP2Base()`, so
that loads, stores and moves of those registers would work. But I
didn't realise that that would also enable all the operations on those
types by default.

Now, if the target doesn't have basic VFP, we follow up those
`addRegisterClass` calls by turning back off all the nontrivial
operations you can perform on f32 and f64. That causes several
knock-on failures, which are fixed by allowing the `VMOVDcc` and
`VMOVScc` instructions to be selected even if all you have is
`HasFPRegs`, and adjusting several checks for 'is this a double in a
single-precision-only world?' to the more general 'is this any FP type
we can't do arithmetic on?'. Between those, the whole of the
`float-ops.ll` and `fp16-instructions.ll` tests can now run in
MVE-without-FP mode and generate correct-looking code.

One odd side effect is that I had to relax the check lines in that
test so that they permit test functions like `add_f` to be generated
as tailcalls to software FP library functions, instead of ordinary
calls. Doing that is entirely legal, but the mystery is why this is
the first RUN line that's needed the relaxation: on the usual kind of
non-FP target, no tailcalls ever seem to be generated. Going by the
llc messages, I think `SoftenFloatResult` must be perturbing the code
generation in some way, but that's as much as I can guess.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D63938

Files:
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/lib/Target/ARM/ARMISelLowering.h
  llvm/lib/Target/ARM/ARMInstrVFP.td
  llvm/test/CodeGen/ARM/fp16-instructions.ll
  llvm/test/CodeGen/Thumb2/float-ops.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D63938.207076.patch
Type: text/x-patch
Size: 9667 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190628/87deb58a/attachment.bin>