[PATCH][AArch64] Implemented vmul/vmux intrinsics

Ana Pazos apazos at codeaurora.org
Thu Nov 14 12:40:08 PST 2013

OK I will allow the non-neon instructions for these intrinsics and implement
them as the other scalar by element arithmetic intrinsics.

Will the ARM Emperor test (that validates all ACLE inntrinscis) pass
regardless of how an intrinsic is implemented?


-----Original Message-----
From: Tim Northover [mailto:t.p.northover at gmail.com] 
Sent: Thursday, November 14, 2013 12:18 PM
To: Ana Pazos
Cc: llvm-commits; cfe-commits at cs.uiuc.edu; Jiangning Liu
Subject: Re: [PATCH][AArch64] Implemented vmul/vmux intrinsics

> The vmul_lane_f64 and the others mentioned below are legacy intrinsics 
> with parameters of v1f64 type:
>     v1if64  vmul_lane_f64 (v1f64 a,  v1if64 v, i32 o)
> The compiler ends up getting rid of the vectors.

Ah, I see. So it's specifically that you want "vmul_lane_f64(x, y, 0)"
to produce "fmul d0, d0, v0.2[0]" rather than "fmul d0, d0, d0"?

If so, I don't think that's a property worth preserving. We were forced into
ugly scalar pseudo-vectors due to lack of global isel, which doesn't apply
here. I can't see any good reason to force the compiler in this case: the
instructions are completely interchangeable.



More information about the llvm-commits mailing list