forked from OSchip/llvm-project
[AArch64] Remove integer INSvi*lane patterns. NFCI.
Most are redundant, and they never seem to fire. The V128 integer patterns already exist in the INS multiclass. The duplicates only fire when the vector index type isn't i64, because they accept "imm" instead of an explicit "i64", as the instruction definition patterns do. TLI::getVectorIdxTy is i64 on AArch64, so this should never happen. Also, one of them had a typo: for i64, INSvi32lane was used. I noticed because I mistakenly used an explicit i32 as the idx type, and got ins.s for an i64 vector_insert. The V64 patterns also don't seem to ever fire, as V64 vector extract/insert are legalized to V128. The equivalent float patterns are unique and useful, so keep them. No functional change intended; none exhibited on the LIT and LNT tests. llvm-svn: 231838
This commit is contained in:
parent
99fb8d17ec
commit
8f6a115de9
|
@ -3724,10 +3724,6 @@ multiclass Neon_INS_elt_pattern<ValueType VT128, ValueType VT64,
|
||||||
defm : Neon_INS_elt_pattern<v8f16, v4f16, f16, INSvi16lane>;
|
defm : Neon_INS_elt_pattern<v8f16, v4f16, f16, INSvi16lane>;
|
||||||
defm : Neon_INS_elt_pattern<v4f32, v2f32, f32, INSvi32lane>;
|
defm : Neon_INS_elt_pattern<v4f32, v2f32, f32, INSvi32lane>;
|
||||||
defm : Neon_INS_elt_pattern<v2f64, v1f64, f64, INSvi64lane>;
|
defm : Neon_INS_elt_pattern<v2f64, v1f64, f64, INSvi64lane>;
|
||||||
defm : Neon_INS_elt_pattern<v16i8, v8i8, i32, INSvi8lane>;
|
|
||||||
defm : Neon_INS_elt_pattern<v8i16, v4i16, i32, INSvi16lane>;
|
|
||||||
defm : Neon_INS_elt_pattern<v4i32, v2i32, i32, INSvi32lane>;
|
|
||||||
defm : Neon_INS_elt_pattern<v2i64, v1i64, i64, INSvi32lane>;
|
|
||||||
|
|
||||||
|
|
||||||
// Floating point vector extractions are codegen'd as either a sequence of
|
// Floating point vector extractions are codegen'd as either a sequence of
|
||||||
|
|
Loading…
Reference in New Issue