[PATCH][AArch64] Implemented vmul/vmux intrinsics
apazos at codeaurora.org
Thu Nov 14 12:07:44 PST 2013
It is not a matter of pair with duplicate functionality. It is compiler
The new aarch64 intriniscs vmuld_lane_f64 works fine because it has the
input/return parameter as double:
double vmuld_lane_f64(double a, v1f64 v, i32 i)
I can look for the pattern:
b = Extract vector v [i]
fmul a, b
And it gets mapped to a fmul d0, d1, v1.d Neon scalar operation.
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.
From: Tim Northover [mailto:t.p.northover at gmail.com]
Sent: Thursday, November 14, 2013 9:57 AM
To: Ana Pazos
Cc: llvm-commits; cfe-commits at cs.uiuc.edu; Jiangning Liu
Subject: Re: [PATCH][AArch64] Implemented vmul/vmux intrinsics
> But to force vmul_n_f64, vmul_lane_f64, vmul_laneq_f64 legacy intrinsics
to map to Neon scalar operations I had to add an aarch64 IR intrinsic.
I don't see why that's an issue in this case. Since floating-point
operations take place in FP-registers anyway, there should be no pair with
duplicated functionality. Could you give an example of some code that
wouldn't work as expected with a natural IR mapping?
More information about the llvm-commits