search for: llvmanypointertype

...> hand written the rest of the tests, combine them with my current output and > what Michael contributed earlier. > > For people who interested in why intrinsics TableGen information is not > precise and accurate, the main reason is that we simply ignores all type > specified with LLVMAnyPointerType. LLVMAnyPointerType essentially support > all types and encode the name into the function name. I found the original > intention to add LLVMAnyPointerType is to specify a pointer of certain type > in any address space, but it seems never care about the type. What makes it > worse is tha...

> On Sep 19, 2014, at 9:57 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > So the proposal is that during development new features are added to > test/Features/compatibility.ll (or some other name). When 3.6 is > released, we will > > * assemble the file with llvm-as-3.6. > * Check in the .bc file as test/Features/Input/compatibility-3.6.bc > *

Hi, The ldN like intrinsics (including all the ld1xN, ldN, ldNlane, ldNr, stN, stNlane) can use any pointer types. The definition (in IntrinsicsAArch64.td) of such intrinsics use 'LLVMAnyPointerType', which means we can pass any pointer type to such intrinsics. E.g. I tried following case ld2.ll: define { <4 x i32>, <4 x i32> } @test(float* %ptr) { %vld2 = call { <4 x i32>, <4 x i32> } @llvm.aarch64.neon.ld2.v4i32.p0f32(float* %ptr) ret { <4 x i32>,...

To avoid going too off-topic on the multidimensional gep thread, I'm asking this in a separate thread. >> I took a look earlier and didn't notice any target-independent ones that would need a separate type parameter Do you know what would happen with the llvm.ptr.annotation intrinsic? Frontends use that to annotate members of structs: struct S { [[some_annotation]] int