[PATCH] D99324: [AArch64][SVE] Simplify codegen of svdup_lane intrinsic

Bin Cheng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Mar 27 07:42:25 PDT 2021


bin.cheng-ali added a comment.

In D99324#2652779 <https://reviews.llvm.org/D99324#2652779>, @paulwalker-arm wrote:

> In D99324#2652288 <https://reviews.llvm.org/D99324#2652288>, @bin.cheng-ali wrote:
>
>> Excuse me, I am new to LLVM/backend, one question is: What does "stock LLVM IR" mean(refer to) in above comment?
>
> By stock LLVM IR I'm referring to the LLVM instructions as defined by the LandRef plus non-target specific intrinsics.
>
>> As for the patch, I am trying to understand the issue, do you suggest we should first introduce DUP_LANE pattern similar to SVDOT_LANE_S so that clang CodeGen doesn't generate dup.x when possible?
>
> I'm not sure I fully understand your question but in general when it comes to code generation I'm trying to ensure where possible that we have a canonicalised representation so that we minimise the number of patterns (IR or DAG) that end up resolving to the same instruction.

I was thinking to introduce below like sve intrinsic pattern so that clang CodeGen generates dup_index directly for const imm_index.
def SVDUP_LANE_IMM   : SInst<"svdup_lane[_{d}]",  "ddi",  "csilUcUsUiUlhfd", MergeNone, "aarch64_sve_dup_index", [], [ImmCheck<1, ImmCheck0_31, 1>]>;
However, this seems impossible because this BuiltIn is the same as SVDUP_LANE and results in compilation error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99324



More information about the llvm-commits mailing list