> 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.
That's what I'd tend to think too. It's probably reasonable to
encourage the NEON intrinsic to generate a FPR128 load though. We
might well get that if we emitted:
%tmp = load fp128* %addr
%val = bitcast fp128 %tmp to i128
Sometimes opt might come in and mess up the load, but it should catch
a few cases that would otherwise cause extra register traffic.
Cheers.
Tim.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
