De Azevedo Piovezan, Felipe via llvm-dev
2019-Jul-25 11:49 UTC
[llvm-dev] Typeless pointers and intrinsics
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 parameterDo you know what would happen with the llvm.ptr.annotation intrinsic? Frontends use that to annotate members of structs: struct S { [[some_annotation]] int annotated_array[10]; int not_annotated_array[100; }; However, there is a big difference between annotating a pointer of type S*, a pointer of type [10 x i32]*, and a pointer of type i8*. The intrinsic is overloaded for "any pointer" type to allow distinguishing between those three cases. Do you think we can represent this in a different way once pointers become opaque? -----Original Message----- From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tim Northover via llvm-dev Sent: Wednesday, July 24, 2019 4:14 PM To: Michael Kruse <llvmdev at meinersbur.de> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Michael Kruse <llvm at meinersbur.de>; SAHIL GIRISH YERAWAR <cs15btech11044 at iith.ac.in>; Michael Ferguson <mferguson at cray.com>; Tobias Grosser <tobias.grosser at inf.ethz.ch> Subject: Re: [llvm-dev] [RFC] A new multidimensional array indexing intrinsic Hi all, On Wed, 24 Jul 2019 at 16:14, Michael Kruse via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Mmmh, looks like Tim Northover is actively working on typeless/opaque > pointers, e.g. https://reviews.llvm.org/D64203Yep, I'm spending as much time as I can on the project. I think there's not really much chance that it'll be required in this cycle (i.e. when we fork in ~Jan pointers will be distinct IMO). On intrinsics as they affect opaque pointers, I took a look earlier and didn't notice any target-independent ones that would need a separate type parameter, but a couple of target-specific ones did. Unless they were particularly anomalous and implementable by other means, intrinsics will need to develop the ability to specify an abstract "notable type" anyway. Apart from all that, I'm pretty disappointed to see this as an intrinsic though. GEP is such a fundamental part of addressing in LLVM that bifurcating it into an intrinsic for either a language or an analysis seems like we'd be papering over a language deficiency. Cheers. Tim. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Tim Northover via llvm-dev
2019-Jul-25 12:04 UTC
[llvm-dev] Typeless pointers and intrinsics
On Thu, 25 Jul 2019 at 12:49, De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com> wrote:> >> 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 annotated_array[10]; > int not_annotated_array[100; > }; > > However, there is a big difference between annotating a pointer of type S*, a pointer of type [10 x i32]*, and a pointer of type i8*. The intrinsic is overloaded for "any pointer" type to allow distinguishing between those three cases. Do you think we can represent this in a different way once pointers become opaque?I hadn't thought about that one specifically. I'm not entirely convinced it merits special treatment if I'm honest: I can't imagine we'd add an extra facility if we were designing the facility from scratch in a world with opaque pointers; we'd probably just tell people to mangle the type into the string somehow if it matters to them since the whole point is to provide such a side channel anyway. That said, I strongly suspect at least one intrinsic *will* need an extra parameter, and once the machinery is in place applying it to @llvm.ptr.annotate wouldn't be difficult if we do decide it's a good idea. Cheers. Tim.
Sidorov, Dmitry via llvm-dev
2019-Aug-14 14:27 UTC
[llvm-dev] Typeless pointers and intrinsics
Hi, Speaking of llvm.ptr.annotation intrinsic. From LLVM Lang ref: "This is an overloaded intrinsic. You can use ‘llvm.ptr.annotation’ on a pointer to an integer of any width." Also in Intrinsics.td ptr.annotation is defined with LLVMAnyPointerType<llvm_anyint_ty>. But in the same time I was able to generate the intrinsic with any other but integer types, for example for union: "@llvm.ptr.annotation.p0s_union._ZTS2un.uns(%union._ZTS2un.un , i8, i8*, i32)". And verifier accepted this code! So from what I see, it's a bug in verifier, that doesn't check for a pointer type. But having typeless ptr.annotation intrinsic seems to be a very useful feature, so does it make sense to make lang ref reflecting todays reality instead of adding this missed type check? -Dmitry Sidorov -----Original Message----- From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim Northover via llvm-dev Sent: Thursday, July 25, 2019 3:04 PM To: De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Typeless pointers and intrinsics On Thu, 25 Jul 2019 at 12:49, De Azevedo Piovezan, Felipe <felipe.de.azevedo.piovezan at intel.com> wrote:> >> 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 annotated_array[10]; > int not_annotated_array[100; > }; > > However, there is a big difference between annotating a pointer of type S*, a pointer of type [10 x i32]*, and a pointer of type i8*. The intrinsic is overloaded for "any pointer" type to allow distinguishing between those three cases. Do you think we can represent this in a different way once pointers become opaque?I hadn't thought about that one specifically. I'm not entirely convinced it merits special treatment if I'm honest: I can't imagine we'd add an extra facility if we were designing the facility from scratch in a world with opaque pointers; we'd probably just tell people to mangle the type into the string somehow if it matters to them since the whole point is to provide such a side channel anyway. That said, I strongly suspect at least one intrinsic *will* need an extra parameter, and once the machinery is in place applying it to @llvm.ptr.annotate wouldn't be difficult if we do decide it's a good idea. Cheers. Tim. _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------------------------------------------------------------- Joint Stock Company Intel A/O Registered legal address: Krylatsky Hills Business Park, 17 Krylatskaya Str., Bldg 4, Moscow 121614, Russian Federation This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Seemingly Similar Threads
- Question about a AA result and its use in Dependence Analysis
- Question about a AA result and its use in Dependence Analysis
- Question about a AA result and its use in Dependence Analysis
- Dependence Analysis bug or undefined behavior?
- Question about a AA result and its use in Dependence Analysis