llvm-project/llvm/test/Assembler/getelementptr_vec_idx3.ll

; RUN: not llvm-as < %s >/dev/null 2> %t
; RUN: FileCheck %s < %t
; Test that a vector GEP may be used with a scalar base, the result is a vector of pointers

; CHECK: '%w' defined with type '<2 x ptr>'

define <4 x i32> @test(ptr %a) {
  %w = getelementptr <4 x i32>, ptr %a, <2 x i32> <i32 5, i32 9>
  ret i32 %w
}
Relax the restrictions on vector of pointer types, and vector getelementptr. Previously in a vector of pointers, the pointer couldn't be any pointer type, it had to be a pointer to an integer or floating point type. This is a hassle for dragonegg because the GCC vectorizer happily produces vectors of pointers where the pointer is a pointer to a struct or whatever. Vector getelementptr was restricted to just one index, but now that vectors of pointers can have any pointer type it is more natural to allow arbitrary vector getelementptrs. There is however the issue of struct GEPs, where if each lane chose different struct fields then from that point on each lane will be working down into unrelated types. This seems like too much pain for too little gain, so when you have a vector struct index all the elements are required to be the same. llvm-svn: 167828 2012-11-13 12:59:33 +00:00			`; RUN: not llvm-as < %s >/dev/null 2> %t`
			`; RUN: FileCheck %s < %t`
Extended syntax of vector version of getelementptr instruction. The justification of this change is here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/082989.html According to the current GEP syntax, vector GEP requires that each index must be a vector with the same number of elements. %A = getelementptr i8, <4 x i8> %ptrs, <4 x i64> %offsets In this implementation I let each index be or vector or scalar. All vector indices must have the same number of elements. The scalar value will mean the splat vector value. (1) %A = getelementptr i8, i8 %ptr, <4 x i64> %offsets or (2) %A = getelementptr i8, <4 x i8> %ptrs, i64 %offset In all cases the %A type is <4 x i8> In the case (2) we add the same offset to all pointers. The case (1) covers C[B[i]] case, when we have the same base C and different offsets B[i]. The documentation is updated. http://reviews.llvm.org/D10496 llvm-svn: 241788 2015-07-09 07:42:48 +00:00			`; Test that a vector GEP may be used with a scalar base, the result is a vector of pointers`
Relax the restrictions on vector of pointer types, and vector getelementptr. Previously in a vector of pointers, the pointer couldn't be any pointer type, it had to be a pointer to an integer or floating point type. This is a hassle for dragonegg because the GCC vectorizer happily produces vectors of pointers where the pointer is a pointer to a struct or whatever. Vector getelementptr was restricted to just one index, but now that vectors of pointers can have any pointer type it is more natural to allow arbitrary vector getelementptrs. There is however the issue of struct GEPs, where if each lane chose different struct fields then from that point on each lane will be working down into unrelated types. This seems like too much pain for too little gain, so when you have a vector struct index all the elements are required to be the same. llvm-svn: 167828 2012-11-13 12:59:33 +00:00
[Assembler] Convert tests to opaque pointers (NFC) Some tests are removed because the error conditions can no longer occur with opaque pointers. 2022-12-13 14:12:34 +01:00			`; CHECK: '%w' defined with type '<2 x ptr>'`
Relax the restrictions on vector of pointer types, and vector getelementptr. Previously in a vector of pointers, the pointer couldn't be any pointer type, it had to be a pointer to an integer or floating point type. This is a hassle for dragonegg because the GCC vectorizer happily produces vectors of pointers where the pointer is a pointer to a struct or whatever. Vector getelementptr was restricted to just one index, but now that vectors of pointers can have any pointer type it is more natural to allow arbitrary vector getelementptrs. There is however the issue of struct GEPs, where if each lane chose different struct fields then from that point on each lane will be working down into unrelated types. This seems like too much pain for too little gain, so when you have a vector struct index all the elements are required to be the same. llvm-svn: 167828 2012-11-13 12:59:33 +00:00
[Assembler] Convert tests to opaque pointers (NFC) Some tests are removed because the error conditions can no longer occur with opaque pointers. 2022-12-13 14:12:34 +01:00			`define <4 x i32> @test(ptr %a) {`
			`%w = getelementptr <4 x i32>, ptr %a, <2 x i32> <i32 5, i32 9>`
Relax the restrictions on vector of pointer types, and vector getelementptr. Previously in a vector of pointers, the pointer couldn't be any pointer type, it had to be a pointer to an integer or floating point type. This is a hassle for dragonegg because the GCC vectorizer happily produces vectors of pointers where the pointer is a pointer to a struct or whatever. Vector getelementptr was restricted to just one index, but now that vectors of pointers can have any pointer type it is more natural to allow arbitrary vector getelementptrs. There is however the issue of struct GEPs, where if each lane chose different struct fields then from that point on each lane will be working down into unrelated types. This seems like too much pain for too little gain, so when you have a vector struct index all the elements are required to be the same. llvm-svn: 167828 2012-11-13 12:59:33 +00:00			`ret i32 %w`
			`}`