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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.
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"! |
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! |
Removed the new operand classes for complex rotation, and added new operand classes for fixed-point VCVT immediates which do the error checking.
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"!