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
idea.
Cheers.
Tim.
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