This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Add a batch of MVE floating-point instructions.
ClosedPublic

Authored by simon_tatham on May 30 2019, 8:21 AM.

Details

Summary

This includes floating-point basic arithmetic (add/sub/multiply),
complex add/multiply, unary negation and absolute value, rounding to
integer value, and conversion to/from integer formats.

Diff Detail

Event Timeline

simon_tatham created this revision.May 30 2019, 8:21 AM

Remastered patch to apply cleanly against current trunk.

miyuki added a subscriber: miyuki.Jun 11 2019, 5:54 AM

Renamed instruction ids in line with the new policy (start with MVE_ and don't refer to opaque ArmARM encoding indices).

Added the floating-point VMINNMA / VMAXNMA instructions to this patch, which were mistakenly included in D62677 despite not being derived from the latter patch's shared base class.

ostannard added inline comments.
llvm/lib/Target/ARM/ARMInstrInfo.td
464 ↗(On Diff #205768)

This looks very similar to ComplexRotationOperand, can we re-use that or do these differ in some way?

llvm/lib/Target/ARM/ARMInstrMVE.td
2086

The neon_vcvt_imm32 operand doesn't have any range checks, which need to differ between f16 and f32 versions. I think this is inherited from NEON, which currently accepts nonsense like "vcvt.f32.u32 q0, q1, #1234"!

simon_tatham marked 2 inline comments as done.Jun 21 2019, 1:45 AM
simon_tatham added inline comments.
llvm/lib/Target/ARM/ARMInstrInfo.td
464 ↗(On Diff #205768)

Apparently we can, and it improves the error messages as well ("complex rotation must be 90 or 270" in place of the all-purpose "invalid operand for instruction").

The semantic difference seems to be that with ComplexRotationOperand, the immediate at the MCOperand level is a small integer like 0,1,2,3, and the conversion between that and multiples of 90° is done at assembly↔MC conversion time, whereas VCMLARotImm stores the immediate in degrees even in the MC representation and translates it at encode/decode time.

Personally I slightly prefer the latter way of doing it, but obviously not enough to make the MVE and NEON implementations deliberately different from each other, now you point it out!

simon_tatham marked an inline comment as done.

Removed the new operand classes for complex rotation, and added new operand classes for fixed-point VCVT immediates which do the error checking.

This revision is now accepted and ready to land.Jun 21 2019, 2:03 AM
This revision was automatically updated to reflect the committed changes.