[ARM] Allow selecting hard-float ABI in integer-only MVE.
authorSimon Tatham <simon.tatham@arm.com>
Tue, 31 Jan 2023 17:31:33 +0000 (17:31 +0000)
committerSimon Tatham <simon.tatham@arm.com>
Wed, 1 Feb 2023 09:05:12 +0000 (09:05 +0000)
commit60ea6f35a270d11c91770a2fc366888e7d3859f4
tree583c183ff2930d758af0c616a7aab659b3b9606c
parentf1c4f927f7c15b5efdc3589c050fd0513bf6b303
[ARM] Allow selecting hard-float ABI in integer-only MVE.

Armv8.1-M can be configured to support the integer subset of the MVE
vector instructions, and no floating point. In that situation, the FP
and vector registers still exist, and so do the load, store and move
instructions that transfer data in and out of them. So there's no
reason the hard floating point ABI can't be supported, and you might
reasonably want to use it, for the sake of intrinsics-based code
passing explicit MVE vector types between functions.

But the selection of the hard float ABI in the backend was gated on
Subtarget->hasVFP2Base(), which is false in the case of integer MVE
and no FP.

As a result, you'd silently get the soft float ABI even if you
deliberately tried to select it, e.g. with clang options such as
--target=arm-none-eabi -mfloat-abi=hard -march=armv8.1m.main+nofp+mve

The hard float ABI should have been gated on the weaker condition
Subtarget->hasFPRegs(), because the only requirement for being able to
pass arguments in the FP registers is that the registers themselves
should exist.

I haven't added a new test, because changing the existing
CodeGen/Thumb2/float-ops.ll test seemed sufficient. But I've added a
comment explaining why the results are expected to be what they are.

Reviewed By: lenary

Differential Revision: https://reviews.llvm.org/D142703
clang/docs/ReleaseNotes.rst
llvm/docs/ReleaseNotes.rst
llvm/lib/Target/ARM/ARMFastISel.cpp
llvm/lib/Target/ARM/ARMISelLowering.cpp
llvm/test/CodeGen/Thumb2/float-ops.ll