<div dir="ltr">Hi Tim,<div><br></div><div>Thanks for your review. Previously, I tried normal load/store, llvm will use two GPR64 instead of FPR128 to store poly128. And because of this, each load/store of poly128 will emit 2 load/store operations on two GPR64. To solve this, I need to bind i128 to FPR128, while it may cause more trouble as AArch64 doesn't really support i128. If end-user want to make some 128-bit calculation on aarch64 target,  mostly he'll get some trouble.</div>
<div>Also, I don't want bind i128 load/store to FPR128. In fact, NEON only provide 1 calculation(PMULL) working on i128. So I guess for most of the case loading or storing i128, the data will be used by some library functions running on cores instead of NEON, so storing i128 to two GPR64 is more general.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/6 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">
<br>
  Hi Kevin,<br>
<br>
  I think the load/store intrinsics are unnecessary; you can use a normal load or store instruction here quite happily (perhaps with a bitcast around it, though even that's probably excessive).<br>
<br>
  The pmull changes look reasonable though.<br>
<br>
  Cheers.<br>
<br>
  Tim.<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D2344" target="_blank">http://llvm-reviews.chandlerc.com/D2344</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards,<div><br></div><div>Kevin Qin</div></div>
</div>