<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Tim,</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 for your detailed explanation, and I can understand your point now now.</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">
In my mind, LLVM IR intrinsic can be treated as a kind of common LLVM IR extension to implement special semantics for specific targets. Generally a common LLVM IR opcode like add/sub can accept different types of operands as a overload behavior. So comparing to common LLVM IR, it make sense to overload LLVM IR intrinsic with different types of operands, if only every overloaded intrinsic can finally map to unique instruction. This sounds like n:1 mapping from LLVM IR intrinsic to hardware instructions.</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">For this specific case, I don't really see <span style="font-family:arial,sans-serif;font-size:14.399999618530273px">llvm.arm.neon.vld2lane.v8i8 </span>would introduce side effects to middle-end and back-end. Semantically it is almost the same as <span style="font-family:arial,sans-serif;font-size:14.399999618530273px">llvm.arm.neon.vld2lane.v16i8</span>, and we can say they will be translated into an unique hardware instruction at the very beginning of compilation stages. As far as the complexity of implementation concerned, I think they are comparable.</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">However, I think you are right the 1:1 mapping from LLVM IR intrinsic to hardware instruction would be helpful to maintain a robust compiler infrastructure, so now I'm OK to move forward to refactor this piece of code.</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 class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/25 Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> This sounds good, and we are suggesting using EXTRACT_SUBREG and friends, so<br>
> we are on the same page, right?<br>
<br>
</div>I'm not suggesting creating the EXTRACT_SUBREGs as a special-case in<br>
AArch64 code, but leaving it to generic handling of shuffles. The less<br>
special-cases we have to deal with, the better.<br>
<div class="im"><br>
> I don't understand about this. Can you explicitly point out what intrinsics<br>
> names are really unnecessary?<br>
<br>
</div>These two are distinct intrinsics:<br>
<br>
{ <16 x i8>, <16 x i8> } @llvm.arm.neon.vld2lane.v16i8(i8*, <16 x i8>,<br>
<16 x i8>, i32, i32)<br>
{ <8 x i8>, <8 x i8> } @llvm.arm.neon.vld2lane.v8i8(i8*, <8 x i8>, <8<br>
x i8>, i32, i32)<br>
<br>
The first maps directly to the AArch64 instruction, the second needs<br>
backend hacks to put it into a form suitable for precisely the same<br>
instruction as the first.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></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>