OSDN Git Service

[ARM] Stop using scalar FP instructions in integer-only MVE mode.
authorSimon Tatham <simon.tatham@arm.com>
Tue, 2 Jul 2019 11:26:00 +0000 (11:26 +0000)
committerSimon Tatham <simon.tatham@arm.com>
Tue, 2 Jul 2019 11:26:00 +0000 (11:26 +0000)
commit47fd66ab1604b29b2a2102216ef242111a563308
tree42b8412bd6156a32e44dd64d0c35ab609439e9b0
parent3d796651b5a843f4a63a1f337adc2f2cd11a5743
[ARM] Stop using scalar FP instructions in integer-only MVE mode.

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, 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.

Reviewers: dmgreen, ostannard

Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@364909 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/ARM/ARMISelLowering.cpp
lib/Target/ARM/ARMISelLowering.h
lib/Target/ARM/ARMInstrVFP.td
test/CodeGen/ARM/fp16-instructions.ll
test/CodeGen/Thumb2/float-ops.ll