Hao Liu
2015-May-05 03:20 UTC
[LLVMdev] [AArch64] Should we restrict to the pointer type used in ldN/stN intrinsics?
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>, <4 x i32> } %vld2 } declare { <4 x i32>, <4 x i32> } @llvm.aarch64.neon.ld2.v4i32.p0f32(float*) It can pass and generate ld2 with "llc -march=aarch64 < ld2.ll". I just think it's strange that the pointer has no relationship with the returned type. Currently there are IR regression test cases using different kinds of pointers like 'xx.ld2.v4i32.p0i32', 'xx.ld2.v4i32.p0v4i32' or 'xx.ld2.v4i32.p0i8', which looks confusing. Should we modify the definition of such intrinsics and restrict the pointer type? If you agree with me, I suggest to use a pointer type to the vector element. Because the 'arm_neon.h' declare the ld2 intrinsic like 'int32x2x2_t vld2_s32(int32_t const * ptr)', which also uses a pointer to the vector element. To achieve this is easy, I have a patch to add a constraint 'PointerToVectorElt' in 'intrinsics.td'. I just wonder if such modification is reasonable. Thanks, -Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150505/f15685fa/attachment.html>
Tim Northover
2015-May-05 04:11 UTC
[LLVMdev] [AArch64] Should we restrict to the pointer type used in ldN/stN intrinsics?
Hi Hao,> I just think it’s strange that the pointer has no relationship with the > returned type. Currently there are IR regression test cases using different > kinds of pointers like ‘xx.ld2.v4i32.p0i32’, ‘xx.ld2.v4i32.p0v4i32’ or > ‘xx.ld2.v4i32.p0i8’, which looks confusing. Should we modify the definition > of such intrinsics and restrict the pointer type?I'm not sure I'd bother. We're hoping to move to a single pointer type throughout LLVM, and this sounds like something that would just have to be undone when we do. On the other hand, there's not been much actual progress there for a while, at least that I've noticed. Is is causing actual problems that you've seen, or is it a cleanliness goal? Cheers. Tim.
Hao Liu
2015-May-05 04:24 UTC
[LLVMdev] [AArch64] Should we restrict to the pointer type used in ldN/stN intrinsics?
Hi Tim, No actual problems. It's just a cleanliness goal. It's OK that we keep it as current status. Thanks, -Hao>-----Original Message----- >From: Tim Northover [mailto:t.p.northover at gmail.com] >Sent: 2015年5月5日 12:12 >To: Hao Liu >Cc: Ahmed Bougacha; LLVM Developers Mailing List >Subject: Re: [LLVMdev][AArch64] Should we restrict to the pointer type used in >ldN/stN intrinsics? > >Hi Hao, > >> I just think it’s strange that the pointer has no relationship with >> the returned type. Currently there are IR regression test cases using >> different kinds of pointers like ‘xx.ld2.v4i32.p0i32’, >> ‘xx.ld2.v4i32.p0v4i32’ or ‘xx.ld2.v4i32.p0i8’, which looks confusing. >> Should we modify the definition of such intrinsics and restrict the pointer >type? > >I'm not sure I'd bother. We're hoping to move to a single pointer type >throughout LLVM, and this sounds like something that would just have to be >undone when we do. On the other hand, there's not been much actual progress >there for a while, at least that I've noticed. > >Is is causing actual problems that you've seen, or is it a cleanliness goal? > >Cheers. > >Tim.
Seemingly Similar Threads
- [LLVMdev] [LLVMDev] Register Allocation and copy instructions
- [LLVMdev] Avoiding load narrowing in DAGCombiner
- [LLVMdev] Unused argument registers can not be reused ?
- [LLVMdev] Scheduling question (memory dependency)
- [LLVMdev] Scheduling question (memory dependency)