[PATCH] D128665: [AArch64] Make nxv1i1 types a legal type for SVE.

Wed Jun 29 13:30:50 PDT 2022

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

LGTM

================
Comment at: llvm/test/CodeGen/AArch64/sve-intrinsics-pred-creation.ll:48
+; CHECK: ptrue p0.d
+; CHECK-NEXT: punpklo p0.h, p0.b
+; CHECK-NEXT: ret
----------------
sdesmalen wrote:
> efriedma wrote:
> > sdesmalen wrote:
> > > efriedma wrote:
> > > > I don't think, in general, we guarantee that padding bits of SVE predicates are zeroed.  So the punpklo should be unnecessary.
> > > I wasn't sure about this to be honest. If we can assume that the other lanes are always zeroed, then we can avoid having to always unpack the predicate when using this value (rather than when creating it). For example, the patterns for `AArch64ptest` don't first mask the predicate with a `ptrue <required element type>` and the instruction always tests each bit. That made me question if it was safe to assume the other lanes are always known to be zeroed.
> > As far as I know, nothing has changed since we last discussed this in https://reviews.llvm.org/D74471 .  Unless I'm forgetting something...
> You're right, in general the other lanes in the vector are indeed undef.
> 
> For the ptrue/splat(1) case I think we want to make an exception and make sure we generate a predicate where the other lanes are zeroed, such that we can use this value to AND with other predicates for explicitly zeroing the other lanes.
I agree we need some way to generate a predicate with the other lanes zeroed.

I'm not sure llvm.aarch64.sve.ptrue.nxv1i1 should map to that; if we convert.to.svbool or whatever, that should zero out the other bits anyway.  But maybe it's less confusing this way if you have optimizations that specifically check for "ptrue".

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128665