[PATCH] [AArch64 NEON] Support poly128_t and implement relevant intrinsic. -LLVM

Kevin Qin kevinqindev at gmail.com
Fri Dec 6 02:25:13 PST 2013


Hi Tim,

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.
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.


2013/12/6 Tim Northover <t.p.northover at gmail.com>

>
>   Hi Kevin,
>
>   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).
>
>   The pmull changes look reasonable though.
>
>   Cheers.
>
>   Tim.
>
> http://llvm-reviews.chandlerc.com/D2344
>



-- 
Best Regards,

Kevin Qin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131206/fb686fa0/attachment.html>


More information about the cfe-commits mailing list