[PATCH] D85364: [SVE][WIP] Implement lowering for fixed width select

Paul Walker via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 26 05:25:08 PDT 2020


paulwalker-arm added a comment.

In D85364#2234543 <https://reviews.llvm.org/D85364#2234543>, @cameron.mcinally wrote:

> However, when we go to lower this to AArch64ISD::SIGN_EXTEND_INREG_MERGE_PASSTHRU, that operation expects a half vector type for the operand. Here's a special case -- for illustrative purposes only:

To be precise SIGN_EXTEND_INREG_MERGE_PASSTHRU expects its VT operand to have the same number of elements as its data operand.  The element type of the VT operand describes the location of the sign bit that is used when performing the extension.  This is identical to the requirements for  SIGN_EXTEND_INREG.

I'm still not sure of the issue you are highlighting.  When I apply the patch and run the test, the first thing I hit is a selection failure, which is fixed by D86394 <https://reviews.llvm.org/D86394>.  I then hit an assert in AArch64TargetLowering::ReconstructShuffle, which looks like it needs updating to take wide and/or scalable vectors into account.  I just stubbed the call out and the code generation succeeds, albeit with terrible code.  Most of this looks to be due to the lowering of the i1 based load.  When I replace that load with an integer load (matching the size of the floating-point operands) and use an icmp[1] to construct the select mask I get the expected code generation.

[1] We don't have lowering for floating-point compares yet.  I have a work in progress patch but it's proving a little problematic as I'm trying to make use of existing expand code like we do for scalable vectors but it seems the two legalisation paths are not equivalent.


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

https://reviews.llvm.org/D85364



More information about the llvm-commits mailing list