• Rebase
• Avoid TableGen logic in instruction operands and constraints

• Fixed naming inconsistencies
• Removed comments about undefined instructions
• Factored out common parts of:
  • VMINV and VMAXV
  • VMINNMV and VMAXNMV
  • VMLADAV and VMLSDAV
  • VMLALDAV, VMLSLDAV (includes VRMLSLDAVH) and VRMLALDAVH
• Fixed inputs and constraints of non-accumulating instructions
• Split the assembler test into integer and floating point parts

Fixed the tablegen file and tests according to reviewer's comments. Added missing cases to ARMRegisterBankInfo.cpp

In D62651#1525589, @efriedma wrote:

LGTM

We could possibly use a custom inserter to generate the vins sequence, but it would probably involve some benchmarking to make sure there aren't any unexpected performance penalties due to the weird register usage. So I'm happy to put that off for now.

(On a side-note, I think you can insert a float into element zero of a vector with two vext instructions, which is the same number of instructions, but maybe lower latency.)

Changed extraction patterns to avoid using GPRs as intermediate registers.

This caused https://bugs.llvm.org/show_bug.cgi?id=41835

Use a different approach (suggested by Artem).

Abandoning in favor of https://reviews.llvm.org/D50507

ping

Handle return of homogeneous aggregates

Fixed handling of homogeneous aggregates of FP16 vectors

Alternative (Clang) patch: https://reviews.llvm.org/D50507

I have added a hardfp test. Clang has some logic to handle scalar FP16 values, it performs softening when needed (e.g. tools/clang/test/CodeGen/arm-fp16-arguments.c), whereas NEON vectors are lowered into LLVM vector types. So we don't need additional changes neither in Clang nor in the LLVM scalar FP16 handling.

This approach worked, but required handling two more operations in PromoteFloatOperand: PromoteFloatOp_BUILD_VECTOR and PromoteFloatOp_INSERT_VECTOR_ELT, which in my implementation don't actually promote anything but rather do some FP softening. Not sure if there is a better solution.

I tried compiling a fadd <4 x half> and it actually does not work: the type gets legalized into v4i16 and we get an unknown libcall. So, the problem is that we need to soften v4f16 to v4i16 when passing it as a function parameter, but at the same time expand to f32 when performing arithmetics on it. Do you have any suggestion how to implement this correctly? Do any other targets face a similar problem?

x86_64 linux

Abandoning (https://reviews.llvm.org/D46110 has been committed instead)

Added a comment