This is an archive of the discontinued LLVM Phabricator instance.

[SVE][CodeGen] Fix issues with EXTRACT_SUBVECTOR when using scalable FP vectors
ClosedPublic

Authored by david-arm on Aug 7 2020, 4:53 AM.

Details

Summary

In this patch I have fixed two issues:

  1. Our SVE tuple get/set intrinsics were using the wrong constant type

for the index passed to EXTRACT_SUBVECTOR. I have fixed this by using the
function SelectionDAG::getVectorIdxConstant to create the value. Also, I
have updated the documentation for EXTRACT_SUBVECTOR describing what type
the constant index should be and we now enforce this when creating the
node.

  1. The AArch64 backend was missing the appropriate patterns for

extracting certain subvectors (nxv4f16 and nxv2f32) from legal SVE types.
I have added them as part of this patch.

The only way that I could find to test the new patterns was to use the
SVE tuple get intrinsics, although I realise it looks a bit unusual.
Tests added here:

test/CodeGen/AArch64/sve-extract-subvector.ll

Diff Detail

Event Timeline

david-arm created this revision.Aug 7 2020, 4:53 AM
Herald added a project: Restricted Project. · View Herald Transcript

Our SVE tuple get/set intrinsics were using the wrong constant type for the index passed to EXTRACT_SUBVECTOR. I have fixed this to use an integer pointer type.

Does this make a practical difference? If it matters, we should fix it in legalization; this isn't part of the documented target-independent semantics.

Hi @efriedma, I'm happy to try and fix up during the legalisation if you think that EXTRACT_SUBVECTOR should accept MVT::i32? However, I'm not sure how I would fix this during legalisation - would this be in DAGTypeLegalizer::PromoteIntOp_EXTRACT_SUBVECTOR? I originally tried adding extract_subvector patterns similar to how it's done for AArch64 and X86, i.e. using a iPTR or i64 type for the index, but the patterns didn't match because the SVE get/set tuple intrinsics were passing MVT::i32. I had a look at every other instance in the codebase where we create EXTRACT_SUBVECTOR operations and they all either call getIntPtrConstant() or getVectorIdxConstant() to create the index type. So it just seemed like this was the way we're expected to do this. Thanks!

Maybe we should just change the documentation and enforce the rule in SelectionDAG::getNode()? Maybe simpler. I guess it has to be a constant anyway?

Doing it in "legalization" would imply operation legalization, not type legalization, since i32 is a legal type. Probably have to do it in target-specific code, since there isn't any good way to express the rule to LegalizaeDAG.

david-arm updated this revision to Diff 284673.Aug 11 2020, 5:24 AM
david-arm edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Aug 11 2020, 2:16 PM