[PATCH][AArch64] Implemented vmul/vmux intrinsics

Ana Pazos apazos at codeaurora.org
Thu Nov 14 12:07:44 PST 2013

Hi Tim,

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[0] 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.


-----Original Message-----
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

Hi Ana,

> 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 mailing list