[PATCH][AArch64] Implemented vmul/vmux intrinsics

[Jiangning Liu]

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 <apazos at codeaurora.org>

> 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: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.
>
> Cheers.
>
> Tim.
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>



-- 
Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131118/be406761/attachment.html>