[PATCH] D63938: [ARM] Stop using scalar FP instructions in integer-only MVE mode.
Dave Green via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 2 03:49:51 PDT 2019
dmgreen accepted this revision.
dmgreen added a comment.
This revision is now accepted and ready to land.
LGTM with one nit.
================
Comment at: llvm/lib/Target/ARM/ARMISelLowering.cpp:599
+ if (!Subtarget->useSoftFloat() && !Subtarget->isThumb1Only()) {
+ if (Subtarget->hasFPRegs()) {
+ addRegisterClass(MVT::f32, &ARM::SPRRegClass);
----------------
This can still be the same if? To drop a level of indentation.
================
Comment at: llvm/test/CodeGen/Thumb2/float-ops.ll:268
+; ONLYREGS: lsls r2, r2, #31
+; ONLYREGS: vmovne.f32 s2, s0
; HARD: lsls r0, r0, #31
----------------
simon_tatham wrote:
> dmgreen wrote:
> > This is worse than before by the looks of it? We move things into fp registers just to move them out again.
> Perhaps that's true, but I'd rather fix the correctness first and get a set of regression tests passing, and //then// we can worry about recovering the performance with those tests in place to prevent breaking correctness again.
>
> Especially since in the general case it's not really clear how you //should// choose which kind of register to use for a value. Keeping it in an FP register is obviously wasteful in this case, but in another case where register pressure is high, might it save a spill or two? I think getting the right answers in cases larger than this simple one might not be trivial.
My worry is that this will mean every floating point load becomes a vldr, which just ends up being moved into a gpr. This probably isn't a huge deal for performance, as you will likely always be calling a __aeabi_fadd type function, but the codesize would increase quite a bit. I couldn't think of a reason when you _would_ want to load using a vldr (at least it would be fairly uncommon). I imagine that almost every operation would actually be done on a gpr for floats.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D63938/new/
https://reviews.llvm.org/D63938
More information about the llvm-commits
mailing list