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 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




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