[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:
Ahmed Bougacha 2015-03-10 20:37:19 +00:00
parent 99fb8d17ec
commit 8f6a115de9
1 changed files with 0 additions and 4 deletions

View File

@ -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<v4f32, v2f32, f32, INSvi32lane>;
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