[llvm-dev] Typeless pointers and intrinsics

[Sidorov, Dmitry via llvm-dev]

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.