Hi Ana, Emperor test infrastructure needs to run the test to compare the semantic correctness, so it doesn't care if the intrinsic is able to be mapped to a specific instruction.
Actually, we've encountered several other intrinsics, which have the same semantics with specific arguments, so we can only choose one of the instructions to implement them, if we don't have any heuristic rules in compiler to determine which one is better. Thanks, -Jiangning 2013/11/15 Ana Pazos <[email protected]> > 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? > > Thanks, > Ana. > > -----Original Message----- > From: Tim Northover [mailto:[email protected]] > Sent: Thursday, November 14, 2013 12:18 PM > To: Ana Pazos > Cc: llvm-commits; [email protected]; 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. > > Cheers. > > Tim. > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > -- Thanks, -Jiangning
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
