[PATCH] D100398: [AArch64][GlobalISel] Regbankselect + select @llvm.aarch64.neon.uaddlv

[Amara Emerson via Phabricator via llvm-commits]

aemerson accepted this revision.
aemerson added a comment.
This revision is now accepted and ready to land.

LGTM.



================
Comment at: llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp:477
+    return false;
+  case Intrinsic::aarch64_neon_uaddlv:
+    return true;
----------------
paquette wrote:
> aemerson wrote:
> > paquette wrote:
> > > aemerson wrote:
> > > > Can we look up this information using the type signature of the intrinsic instead of hard coding it?
> > > Maybe I'm looking in the wrong place, but it looks like probably not:
> > > 
> > > ```
> > >   class AdvSIMD_1VectorArg_Int_Across_Intrinsic
> > >     : DefaultAttrsIntrinsic<[llvm_anyint_ty], [llvm_anyvector_ty], [IntrNoMem]>;
> > >   ...
> > >   def int_aarch64_neon_uaddlv : AdvSIMD_1VectorArg_Int_Across_Intrinsic;
> > > ```
> > > 
> > > 
> > > 
> > In that case, this intrinsic could define a GPR right? The comment for this function says it's true if the ID only uses and defines FPRs.
> I don't think it's supposed to.
> 
> There are 0 testcases which have a W or X register as the definition for a uaddlv.
> 
> AFAIK from the documentation for uaddlv, it always ends up on a FPR: https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/UADDLV--Unsigned-sum-Long-across-Vector-
> 
> It defines an integer //value// though.
Right, so this function is used to determine which bank to put them on, so we can hard code in the fact that it should be assigned to FPR despite the value type.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100398/new/

https://reviews.llvm.org/D100398