This is an archive of the discontinued LLVM Phabricator instance.

[AArch64][SVE] Ensure PTEST operands have type nxv16i1
ClosedPublic

Authored by RosieSumpter on Jul 7 2022, 6:10 AM.

Details

Summary

Currently any legal predicate types will be pattern-matched when
creating a PTEST instruction. This could be a problem in future since
PTEST always uses the .B specifier for the operand, but it is not
always guaranteed that the extra lanes of unpacked types (e.g. nxv4i1)
are zero. This patch ensures the operands of PTEST are type nxv16i1,
where the undef lanes are set to zero.

Diff Detail

Event Timeline

RosieSumpter created this revision.Jul 7 2022, 6:10 AM
RosieSumpter requested review of this revision.Jul 7 2022, 6:10 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 7 2022, 6:10 AM

Thanks @RosieSumpter for fixing this. Just left a new nits, but overall the changes look sensible to me.

llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
241

nit: isZeroingInactiveLanes ?

16186

nit: Can you propagate MVT::nxv16i1 to all uses of WidenVT, and remove WidenVT?

16187–16188

nit: are ReinterpertOp and ReinterpretPg needed? I think you can just reassign Op and Pg?

RosieSumpter marked 3 inline comments as done.
  • Renamed hasZeroedOtherLanes -> isZeroingInactiveLanes
  • Removed`WidenVT`
  • Used existing Pg and Op instead of defining new ReinterpretPg and ReinterpretOp
Matt added a subscriber: Matt.Jul 7 2022, 3:53 PM
paulwalker-arm added inline comments.Jul 7 2022, 5:11 PM
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
16193

For the same reason as below I think this can be just if (isZeroingInactiveLanes(Op))

16200–16203

Isn't this equivalent to just Pg = getSVEPredicateBitCast(MVT::nxv16i1, Pg, DAG);? because getSVEPredicateBitCast already has the isZeroingInactiveLanes logic. Which means these two cases can be removed as the default case should just work?

llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
2133–2134

Now that we'll only ever have a single pattern, can you do this as part of PTEST_PP's definition?

RosieSumpter marked 3 inline comments as done.
  • Simplified code added to getPTest
  • Moved PTEST's pattern definition
sdesmalen added inline comments.Jul 8 2022, 3:47 AM
llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
782–783

nit: We normally put the pattern in the class definition itself, which has most benefits if there are multiple instructions being instantiated from the same (multi)class, so that we only have to specify the pattern once. In this case, there's only one instantiation from sve_int_ptest, but for consistency and to keep this file tidy, I'd rather see the pattern living in that class.

This means you'll need to make sve_int_ptest a multiclass and pass in AArch64ptest as a SDPatternOperator. You can then also use SVE_2_Op_Pat for the pattern itself.
See for example the definition of class sve_int_pfirst.

paulwalker-arm added inline comments.Jul 8 2022, 3:51 AM
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
16179

Does adding an assert that Op->getValueType() == Pg->getValueTypes() cause any issues, because otherwise I think the AArch64CC::ANY_ACTIVE code in unsafe?

llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
782–783

You can also do this within sve_int_ptest directly by just passing in AArch64ptest. See sve_int_wrffr for inspiration.

RosieSumpter marked 2 inline comments as done.
  • Added assert that PTEST operands have same type
  • Moved PTEST pattern to class definition
llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
16179

Hey Paul, thanks for the comments. I've added the assert - doesn't seem to cause any problems.

This revision is now accepted and ready to land.Jul 11 2022, 12:38 AM
Allen added a subscriber: Allen.Jul 11 2022, 9:26 PM