[PATCH][AArch64] implement 3 aarch64 neon instrunctions (umov smov ins) in llvm

[Jiangning Liu]

Tim,

I think you are meaning VPR128->FPR128->VPR64 is ugly.

So do you mean we should completely remove register class VPR64 in
AArch64RegisterInfo.td? And then we should define a new operand type
derived from RegisterOperand to describe 64-bit vector register operand in
patterns instead?

Thanks,
-Jiangning


2013/9/11 Tim Northover <t.p.northover at gmail.com>

> Hi Kevin,
>
> > I see in AArch64RegisterInfo.td, Vx is defined as subreg of Qx, but
> there is
> > no belonging relation describe between VPR64 and VPR128. How can I define
> > VPR64 is subreg of VPR128 while both of them hold same register name Vx?
> >
> > Or, Do you know any dag node can do such promotion without introducing
> > instruction?
>
> Hmm. This sounds like it might be the reason RegisterOperand was
> created. I mentioned before that Jim Grosbach suggested (back in
> January) we use that instead of our odd scheme with "sub_alias".
> Postponing that move is probably just going to cause more problems in
> the future.
>
> The way to describe it within our current hierarchy would probably be
> an sub_64 extract (the relation is transitive, I believe, so VPR128
> does have FPR64 as its sub_64) followed by a sub_alias insert. I.e.
> VPR128 -> FPR64 -> VPR64. But that's horribly ugly.
>
> Unfortunately I can't reproduce the error you're seeing with any quick
> tests, so this is purely theoretical speculation.
>
> Cheers.
>
> Tim.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130912/0762e04c/attachment.html>