<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hi Ana,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Thanks,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">
-Jiangning  </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/15 Ana Pazos <span dir="ltr"><<a href="mailto:apazos@codeaurora.org" target="_blank">apazos@codeaurora.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OK I will allow the non-neon instructions for these intrinsics and implement<br>
them as the other scalar by element arithmetic intrinsics.<br>
<br>
Will the ARM Emperor test (that validates all ACLE inntrinscis) pass<br>
regardless of how an intrinsic is implemented?<br>
<br>
Thanks,<br>
<div class="im HOEnZb">Ana.<br>
<br>
-----Original Message-----<br>
From: Tim Northover [mailto:<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>]<br>
</div><div class="im HOEnZb">Sent: Thursday, November 14, 2013 12:18 PM<br>
To: Ana Pazos<br>
Cc: llvm-commits; <a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a>; Jiangning Liu<br>
Subject: Re: [PATCH][AArch64] Implemented vmul/vmux intrinsics<br>
<br>
</div><div class="HOEnZb"><div class="h5">> The vmul_lane_f64 and the others mentioned below are legacy intrinsics<br>
> with parameters of v1f64 type:<br>
><br>
>     v1if64  vmul_lane_f64 (v1f64 a,  v1if64 v, i32 o)<br>
><br>
> The compiler ends up getting rid of the vectors.<br>
<br>
Ah, I see. So it's specifically that you want "vmul_lane_f64(x, y, 0)"<br>
to produce "fmul d0, d0, v0.2[0]" rather than "fmul d0, d0, d0"?<br>
<br>
If so, I don't think that's a property worth preserving. We were forced into<br>
ugly scalar pseudo-vectors due to lack of global isel, which doesn't apply<br>
here. I can't see any good reason to force the compiler in this case: the<br>
instructions are completely interchangeable.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font face="courier new, monospace">Thanks,</font><div><font face="courier new, monospace">-Jiangning</font></div></div>
</div>