arc64: vector float conflict between qemu and gcc

[keith-packard]

QEMU seems to believe that vector instructions, like vfsnmadds, use an even and odd register pair. See the VEC_FLOAT4_SCALARD macro here:

qemu/target/arc/semfunc-v3.c

Line 14214 in 76e0fa9

int arc_gen_##NAME(DisasCtxt *ctx, TCGv a, TCGv b, TCGv c, TCGv d) \

along with the implementation of nextFPUReg:

qemu/target/arc/semfunc-helper.c

Line 338 in 76e0fa9

TCGv arc_gen_next_fpu_reg(const DisasCtxt *ctx, TCGv reg, bool fail)

QEMU generates an instruction error exception if an odd register is used for any of the first three operands in these instructions.

On the other hand, GCC has no restrictions on register selection for these same instructions:
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/blob/2a410ccc3a2c44eea48e7b378c025e790a90672c/gcc/config/arc64/arith.md#L2645

picolibc's __rem_pio2f function does two negation operations on sequential array elements here: https://github.com/picolibc/picolibc/blob/34618e00aebc727c63f3ba896f5be5c07b51e8e9/newlib/libm/math/sf_rem_pio2.c#L154 When built with -mfpu=fpud -O3, this generates the following assembly:

.L17:
	mov	r1,0x00000000	# tmp227,
	fld64	f1,[@.LC0]	#, tmp225
	neg_s	r0,r0	# <retval>, <retval>
	vfsins	f1[0],f2	# tmp225,, prephitmp_63
	vfsins	f1[1],f0	# tmp225,, _40
	fmvi2s	f0,r1	# tmp227, tmp227
	vfsnmadds	f1,f1,f0,f1	# vect__41.22, tmp225, tmp227, tmp225

Because this uses f1 for the first two operands, QEMU raises an exception at this point.

I don't have access to the synopsys architecture documents because they are behind a NDA wall, so I don't know what the semantics of the vector instructions actually is, so I can't tell whether there is a bug in QEMU, GCC or both.

[abrodkin]

I don't have access to the synopsys architecture documents because they are behind a NDA wall, so I don't know what the semantics of the vector instructions actually is, so I can't tell whether there is a bug in QEMU, GCC or both.

Well, that's not entirely correct. Exactly for such cases (i.e. the community interest) we've got our PRM's (which stands for "Programmer's Reference Manual") available w/o signing NDAs etc, with a simple click-through form (which unfortunately we cannot remove completely), see https://www.synopsys.com/dw/doc.php/iip/DWC_ARCv3HS6x/ARC_V3_ProgrammersReference_hs6x_public.pdf

But thanks for the report, we'll take a look at it!

[keith-packard]

Well, that's not entirely correct. Exactly for such cases (i.e. the community interest) we've got our PRM's (which stands for "Programmer's Reference Manual") available w/o signing NDAs etc, with a simple click-through form

Thanks! I must not have searched hard enough; I couldn't find the V3 versions, only V2.