Page MenuHomePhabricator

[llvm][SVE] Addressing mode for FF/NF loads.

Authored by fpetrogalli on Mar 15 2020, 9:20 PM.



This patch adds addressing mode computation for the following SVE

  • ldff1{s}<T1> { <Zt>.<T2> }, <Pg>/Z, [<Xn|SP>{, <Xm>{, lsl #imm}}]
  • ldnf1{s}<T1> { <Zt>.<T2> }, <Pg>/Z, [<Xn|SP>{, #<imm>, mul vl}]

Diff Detail

Event Timeline

fpetrogalli created this revision.Mar 15 2020, 9:20 PM
Herald added a reviewer: efriedma. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
andwar added inline comments.Mar 16 2020, 9:54 AM

Is this change needed here?


Why do you have to update this method? I've tried to find the relation with other changes in this file and I failed :)


[Nit] - unrelated



fpetrogalli marked 4 inline comments as done.

Remove unused parameter from test case, and remove empty line.

Thank you for the review @andwar !



I wouldn't say needed, but:

  1. as far as I know, all types handled by this component in LLVM are legal: which meas that it is very unlikely that we will ever enter the brnach code following. If we ever do enter this branch, it means that something elase is broken before in the pipeline. Addressing mode decomposition doesn't seem to me the right place to catch it.
if (NumElts != 2 && NumElts != 4 && NumElts != 8 && NumElts != 16)
  return EVT();
  1. What this method does is "give me a scalable vector of N packed lanes of integers". Whether the "N" comes of a vector of i1 lanes, it doesn't matter. Hence, I think it is better to use ElementCount in input, not a vector EVT of i1lanes. So, I think we can also remove the first if condition.

All in all, I think it makes sense to make the changes you see in this method.


The method SelectAddrModeIndexedSVE operates on the "memory VT" of the underlying SDNode. One it determines it, it uses it to computed the decomposition of the ADD into a Base and an integer MUL VL Offset.

I had to modify this method because it needs to learn how to extract the MemVT from the SDNodes that represent the LDNF/LDFF. I then rearranged the code for the PRF intrinsic because (to me) it made mode sense to handle all cases under the same switch.

It would be nice if we could use the same method to retrieve the memory VT for all the SVE LD intrinsic, but for the custom ISD nodes there is not such thing as getMemoryVT(), like there is for the MemSDNode class.

We could argue to use MemIntrinsicSDNode (which have the getMemoryVT method), but at this point in the lowering sequence the AArch64ISD nodes have replaced the input Intrinsic::aarch64_sve_ld... nodes, so I cannot cast the nodes into instances of MemIntrinsicSDNode.

andwar added inline comments.Mar 17 2020, 6:46 AM

Thank you for the explanation, it makes sense!

  • Still, these changes are unrelated to what this patch is for. I think that this sort of refactoring should happen in a separate patch. If you want to keep it here, could you please list the NFC changes in the commit message?
  • I think that with these changes this method can be replaced with getSVEContainerType.

OK, now I understand, thanks! I think that it would be very helpful to explain this in a comment somewhere within the method. In particular, why does this method differentiate between custom ISD nodes and intrinsics? Otherwise the code is a bit counterintuitive.

It's unfortunate that such a small method requires nested switch statements.


This llvm_unreachable is a bit confusing here (relates to the nested switch). Wouldn't it make more sense to have a default case within the nested switch block?



Thank you for your review @andwar.

I have restored the original code. I will address merging getPackedVectorTypeFromPredicateType into getSVEContainerType in a separate patch, marked as NFC.


fpetrogalli marked 5 inline comments as done.Mar 17 2020, 8:01 AM

I have added CHECK-NEXT where needed.


Cosmetic changes to the formatting of the codegen pattern defs. NFC

Cheers for working on this, LGTM!

andwar accepted this revision.Mar 18 2020, 5:28 AM


This revision is now accepted and ready to land.Mar 18 2020, 5:28 AM
This revision was automatically updated to reflect the committed changes.